I want to match multiple methods, such as GET, POST in the same URL, this URL may have OPTIONS method, I want to exclude OPTIONS.
Knowing through Google, Fiddler Method can only match one method. So I can only set the same forwarding rule for each method
like
METHOD:GET regex:(?inx)^http://test/meter/(?<name>.+)$ METHOD:POST regex:(?inx)^http://test/meter/(?<name>.+)$
Is there a better way for me to match multiple methods?
Related
I have a design question on REST. I need to expose a validate method as a rest resource. Let us say it looks like this
public ValidatedResult validate(ObjectToBeValidated object)
ObjectToBeValidated is a class that contains the actual Object and also some parameters concerning the validation.
When I design this as a Restful resource, which action do I use? From my understanding GET is the action that best suits this case. If that is so, how I can pass my ObjectTobeValidated as an object but not as URL parameters? I shy away from URL parameters because ObjectToBeValidated may contain a lot of properties, ending up with an URL like below which is feel is too long
http://localhost/rest/validate?prop1=somevalu&prop2=somevalue&prop3=something&prop11=somevalu&prop22=somevalue&prop33=something
Any help would be appreciated
Thanks
Kay
The HTTP standard allows you to use the POST method. It does not necessary need to have a side effect.
The action performed by the POST method might not result in a resource
that can be identified by a URI. In this case, either 200 (OK) or 204
(No Content) is the appropriate response status, depending on whether
or not the response includes an entity that describes the result.
HTTP 1.1 / method definitions / POST
In your case you can do something like this if you want to follow the noun-verb approach Tim suggested:
POST /api/my/object/validator
Be aware that by REST the messages must be self-descriptive, so either you need a vendor MIME type or you need to add meta-data e.g. RDF to describe what this link does and what params are allowed. Otherwise we are not talking about REST, just a regular webapp.
I am creating HTTP request using Apache HTTP Client version 4.3.4. I see there are some classes like HttpGet,... and there is also a class BasicHttpRequest. I am not sure which one to use.
Whats the difference and which one should be used in which condition ?
BasicHttpRequest is provided by the core library. As its name suggests it is pretty basic: it enforces no particular method name or type, nor does it attempt to validate the request URI. The URI parameter can be any arbitrary garbage. HttpClient will dutifully transmit it to server as is, if it is unable to parse it to a valid URI.
HttpUriRequest variety on the other hand will enforce specific method type and will require a valid URI. Another important feature is that HttpUriRequest can be aborted at any point of their execution.
You should always be using classes that implement HttpUriRequest per default.
I was just browsing the 4.3.6 javadoc attempting to locate your BasicHttpRequest and was unable to find it. Do you have a reference to the javadoc of this class?
I would be under the impression that BasicHttpRequest would be a base class providing operations and attributes common to more than one HttpRequest. It may be extremely generic for extension purposes.
To the first part of your question, use HttpGet, HttpPost etc for their specific operations. If you only need to HTTP/GET information then use HttpGet, if you need to post a form or document body, then use HttpPost. If you are attempting to use things like the Head, Put, Delete method, then use the correspoding HttpXXX class.
In my app there is a button which (when clicked) should apply some mutation to all entities (of a certain type). Assuming my entities are "purchases" clicking on the "confirm all" button should result in the server/db setting the "confirmed" field of all "purchases" to "true".
I have the code that does this on the server side. My question is this: what is the URI that I should use for this action?
POST seems like a wrong choice as this action is idempotent. Thus, I am left with PUT. two ideas come to mind:
PUT /purchases?confirmed=true
PUT /purchaes/__all__?confirmed=true
Is there any well established convention?
EDIT
There is a third option (suggested by Markus):
PUT /confirmations/?confirmed=true
Of course, this can work and clearly has its merits. The (only) problem that I find with it is the confirmations is not an en entity in my system. In particular there is no GET /confirmations/some_id URI which may be confusing.
Firs of all, the URI you should use for this operation is whatever URI the collection of purchases returned for that action. The URI semantics shouldn't matter.
Second, when we say POST isn't idempotent, what we are saying is that the client can't assume by default that the operation is idempotent. The semantics of the POST method are entirely within your control, and that's why they must be documented and you can't rely on the client knowing beforehand what it does, as is the case with GET, PUT and DELETE.
In simple terms, having a PUT operation that isn't idempotent is a violation of the HTTP method semantics, but having a POST that is idempotent is fine.
Third, what you're doing is RPC, not REST. For instance:
PUT /purchases?confirmed=true
You're simply calling a method by passing parameters. The only way this could make sense in REST would be if you were creating or replacing a set of purchases to replace the subset where confirmed=true, which would be the exact opposite of what you want. If you want to do something like that, you should use POST, not PUT.
It's clear that your confirmation is a partial update, so you shouldn't be using PUT at all. As a general rule, if you're trying to define a separate semantics coupled to a particular resource for GET, PUT, PATCH and DELETE, you're doing wrong. Those methods should be generic and work in the exact same way for everything. If you need to couple some URI and method to a particular resource state transition, do it with POST.
I don't know the details of the API, but it looks like you're using query string parameters as payload parameters interchangeably. That's not a good idea either, since you can't treat URIs as atomic identifiers.
If your URIs were atomic, you could say this returns all unconfirmed purchases:
GET /purchases?confirmed=false
And you could document POST as the method to perform partial updates in bulk, changing the filtered subset:
POST /purchases?confirmed=false
{ "confirmed": true }
If you insist on using PUT, you should do something like this. If you have the URI below which returns a global confirmed status by reducing all purchases with AND:
GET /purchases/confirmation
{ "confirmed": False }
Then you could make something like:
PUT /purchases/confirmation
{ "confirmed": true }
I have code that contains several different DELETE methods, one of which takes a parameter, or at least ideally it would take a parameter. However when I make this request, either through CURL or through a web client, it doesn't work. The other DELETE requests function fine and I've hard-coded in the parameter that I want to pass just to see if the call works and it does. I've tried this with both PathParam and QueryParam and neither works. Here's how I'm using the PathParams, which I'm pretty sure is correct, QueryParams looks very similar so I don't want to post that too.
#DELETE
#Path("/byId/{id}")
public void deleteById(#PathParam("id") String id)
And then essentially the same thing for QueryParams but obviously the path is different
From what I understand a lot of RESTful APIs ignore any kind of request body with a DELETE request, or treat it as a PUT or POST. Is there any way around this? Basically I have a database that contains several objects and I need to delete one based on a unique identifier, to be passed in by the client. If there is no way around this is there some other way that I could do it?
Its possible that I'm missing something obvious here as I've only been using Jersey for a few weeks now and up to this point had never even heard of the concept of RESTful services.
You can send information to a RESTful service as either headers, path param, query param or message body.
If all the values go through as expected there is no problem with jax-rs/jersey. Now you need to debug the code and fix your implementation. jax-rs will only match a DELETE call with the DELETE http method you have implemented.
It is then your responsibility to actually perform a DELETE operation of the resource within the method. jax-rs or jersey is not going to complain if you do not DELETE or if you do some other action within the method.
In REST webservice there is a possibility to say which verbs are possible for specified resource. Can I return any headers specifying that for GET one could pass param, say, 'name' so client knows that he could make:
GET /resource?name=foo
You can make new headers if you like, but they wouldn't be very much in line with the design of the protocol. First of all, it's important to understand that "/bar" identifies a resource, and "/bar?name=foo" identifies a different resource, not the same resource with parameters. I know this is counter to the design of many popular web frameworks, but it's essential for understanding how to use the protocol correctly.
Based on that, the OPTIONS method should return information about the identified resource, which means that OPTIONS /bar should return a response about the communication options of the /bar resource, not the /bar?name={name} set of resources. Note also that OPTIONS has no format specified for a payload; the only interoperable exchange is via well-known headers like Allow.
The proper way for a representation of the resource /bar to contain information about the resource /bar?name=foo is via links (or forms, some of which are a means to construct links), either in the payload (if the media type supports it) retrieved from GET /bar, or in the response headers (more and more commonly via the Link header). Look into URI Templates for an alternative to HTML forms.