I have a route defined like this:
from("direct:performEbayHttpCall")
.setHeader("HTTP_METHOD", constant("GET"))
.setBody(constant(null))
.log("${headers.EBAY_URL}")
.recipientList(simple("http://${headers.EBAY_URL}"))
.unmarshal().json(JsonLibrary.Gson);
When the log endpoint gets called the EBAY_URL is correct, I can copy and paste it into a browser and it works.
However when the http request is made, the url parameters are in completely the wrong order and thus causing a 500 response to be returned from the server.
Is there a way to tell camel to not mess about with the ordering of the url?
No the query parameter ordering should NOT matter. Any HTTP server should accept query parameters in whatever order they are, eg a=1&b=2 is the same as b=2&a=1
Camel validates and normalizes the URI and the query parameters is listed in A..Z order. (nor random).
Related
A url without parameters but with a question mark appended at the end is passed to the client to be parsed and used.
I've been told the client should be robust enough to handle such url and proceed. But shouldn't this be fixed server-side?
thanks
An empty query part is not an error, so it definitely needs to be accepted by the client. (Reference: RFC 3986 section 3.4 which shows the syntax of the query as 0 or more allowable characters.)
An empty query is different from an undefined query (i.e., the URI does not contain a ?). If the base URI contains a query component, merging a relative URI with an empty query will override the base URI's query, whereas merging a relative URI without a query will copy the base URI's query into the merged result.
Is there a way to make a GET request in Siesta, while providing parameter, like http://example.com/api/list.json?myparam=1?
I tried with
myAPI.resource("list.json?myparam=1")
but the question mark gets escaped.
Then I tried with
myAPI.resource("list.json").request(.GET, urlEncoded:["myparam": "1"])
but it always fails with "The network connection was lost.", but all other requests succeed, so the message is wrong.
You are looking for withParam:
myAPI.resource("list.json").withParam("myparam", "1")
The Service.resource(_:) method you are trying to use in your first example specifically avoids interpreting special characters as params (or anything except a path). From the docs:
The path parameter is simply appended to baseURL’s path, and is never interpreted as a URL. Strings such as .., //, ?, and https: have no special meaning; they go directly into the resulting resource’s path, with escaping if necessary.
This is a security feature, meant to prevent user-submitted strings from bleeding into other parts of the URL.
The Resource.request(_:urlEncoded:) method in your second example is for passing parameters in a request body (i.e. with a POST or PUT), not for parameters in the query string.
Note that you can always use Service.resource(absoluteURL:) to construct a URL yourself if you want to bypass Siesta’s URL component isolation and escaping features.
I'm about to lead a training seminar on REST for some coworkers, and I'd like to verify something regarding Rails routing.
Our app in its current form allows clients to specify format in three different ways:
1.
/path/to/resource.json
2.
/path/to/resource?format=json
3.
Accept header of the request
My question pertains to the first 2 options: is there any inherent difference in what these specifications do? Specifically, do they set only the Accept header, or the Content-Type header as well?
Well, 1 and 2 are not exactly different, since Rails typically generates routes like:
/something(.:format)
That means "there is an optional parameter format delimited with a dot". Parameters, however, can also be specified in query string, which is not part of the route.
So the second way of querying for JSON will make the route system think that the format is not in the route at all. When it comes to the controller, however, Rails will already have that query string parsed and will find the format when the time comes to respond.
That said, if you hit plain /path/to/resource without format specified anywhere, you'll get the same result as 2: you hit a route assuming there's no format given. Still, Rails will parse the headers and determine the format it should respond with.
As for what the client needs to set: accept header only, Content-Type only makes sense when the user himself sends an entity, and it's only related to "how should Rails parse incoming parameters", it's not related to response. Of course, by default Rails does its best to set Content-Type of response to be sensible.
Please checkout the following initializers:
https://github.com/rails/rails/blob/756baf296b3cb3f7bc40d5843e259276695071ab/actionpack/lib/action_dispatch/http/response.rb#L113
This is where how they look up for headers content type to set for.
if content_type = self[CONTENT_TYPE]
type, charset = content_type.split(/;\s*charset=/)
#content_type = Mime::Type.lookup(type)
#charset = charset || self.class.default_charset
end
so you can even programatically set content_type to header, or params or as a .format
I am receiving HTTP/SOAP request with some query parameters. Those query parameters are in repeated format as key=value as /q=key1=value1&key2=value2 etc...
I would like to retrieve all the keys from above URL and check if they are valid or not.
1. Is there any way to define global array which can hold these keys
2. How to validate if keys are present or not. Does ESB supports java "contains" API ?
I believe you are doing a GET request..
You can retrieve all the query parameters in a sequence.
eg:
For a request url; http:// localhost:8280/getSimpleQuote?symbol=IBM
<property name="symbol" expression="$url:symbol"/> will return the symbol 'IBM'.
After getting all keys, you can validate them
you can get the query parameters with the xpath expression get-property{'uri.var.xxx'} with xxx is the name of the query parameter you need to get.
When a resource is defined with a URL mapping, only those requests that match the given URL mapping will be processed by the resource. Alternatively one could configure a resource with a URI template. A URI template represents a class of URIs using patterns and variables. Some examples of valid URI templates are given below.
/order/{orderId}
/dictionary/{char}/{word}
All the identifiers within curly braces are considered variables. A URL that matches the template “/order/{orderId}” is given below.
/order/A0001
In the above URL instance, the variable orderId has been assigned the value “A0001”. Similarly following URL adheres to the template “/dictionary/{char}/{word}”.
/dictionary/c/cat
In this case the variable “char” has the value “c” and the variable “word” is given the value “cat”. When a resource is associated with a URI template, all requests that match the template will be processed by the resource. At the same time ESB will provide access to the exact values of the template variables through message context properties. For an example assume a resource configured with the URI template “/dictionary/{char}/{word}”. If the request “/dictionary/c/cat” is sent to the ESB, it will be dispatched to the above resource and we will be able to retrieve the exact values of the two variables using the get-property XPath extension of WSO2 ESB:
As we all know, file uploading is most often accomplished using POST method. So, why can't the GET method be used for file uploads instead? Is there a specific prohibition against HTTP GET uploads?
GET requests may contain an entity body
RFC 2616 does not prevent an entity body as part of a GET request. This is often misunderstood because PHP muddies the waters with its poorly-named $_GET superglobal. $_GET technically has nothing to do with the HTTP GET request method -- it's nothing more than a key-value list of url-encoded parameters from the request URI query string. You can access the $_GET array even if the request was made via POST/PUT/etc. Weird, right? Not a very good abstraction, is it?
Why a GET entity body is a bad idea
So what does the spec say about the GET method ... well:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe."
So the important thing with GET is to make sure any GET request is safe. Still, the prohibition is
only "SHOULD NOT" ... technically HTTP still allows a GET requests to result in an action that isn't
strictly based around "retrieval."
Of course, from a semantic standpoint using a method named GET to perform an action other than
"getting" a resource doesn't make very much sense either.
When a GET entity body is flat-out wrong
Regarding idempotence, the spec says:
Methods can also have the property of "idempotence" in that (aside from error or expiration issues)
the side-effects of N > 0 identical requests is the same as for a single request. The methods GET,
HEAD, PUT and DELETE share this property.
This means that a GET method must not have differing side-effects for multiple requests for the
same resource. So, regardless of the entity body present as part of a GET request, the side-effects
must always be the same. In layman's terms this means that if you send a GET with an entity body
100 times the server cannot create 100 new resources. Whether sent once or 100 times the request must
have the same result. This severely limits the usefulness of the GET method for sending entity bodies.
When in doubt, always fall back to the safety/idempotence tests when evaluating the efficacy
of a method and its resulting side-effects.
In case of GET Method
Appends form-data into the URL in name/value pairs and length of URL is limited(3000 characters).
File content can't be put inside a URL parameter using a form.So use POST
In Get method, the value of action, appends a `?' to it, then appends the form data set, encoded using the "application/x-www-form-urlencoded" content type. The user agent then traverses the link to this URI. In this scenario, form data are restricted to ASCII codes.
So, that file upload is not possible in GET Method