Subject: Grouper Developers Forum
- From: Chris Hyzer <>
- To: Grouper Dev <>
- Subject: quick important REST question
- Date: Tue, 25 Mar 2008 03:24:21 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
Hey REST experts,
I am implementing the member delete REST operation, and I am using the HTTP DELETE method. However, it looks like GET and DELETE cannot have a request body (at least using Jakarta Commons HttpClient).
Sometimes there are no params to this, e.g. delete a member from a group. However, sometimes there are params, e.g. actAs someone, only delete members assigned to a certain list, delete multiple members at once, request group detail in response. These params are in the form of XML / XHTML / JSON / (or query string in body of request, though obviously this isn’t ideal)
So does that mean that the simple delete should use the DELETE method (the one with no params), and if you want to pass params then you use a POST or PUT? If I don’t hear back, that is what I will assume… however, that will be confusing for people implementing a web service client. Simpler would just to use PUT or POST for all operations, but as has been said earlier it is not RESTful. Is there an alternative?
Here it talks about Put and Post having a request entity, and not Delete or Get
While we are here, Im not all that comfortable with the REST service sending back a 500 if there is a problem where a response can be sent back. How does the client differentiate this from a servlet container problem (also 500)? Right now the way is if the X- grouper headers aren’t there, then it is a servlet container 500, but if they are there, then it is a code 500. Im fine doing it this way, but it seems a little awkward… Similarly, if a group isn’t found, a 404 is returned, this is the same code as if the servlet isn’t found. Again im fine leaving it like that so it is restful, but I would not recommend writing a client that depends on http status code at all, just the grouper status code…
- quick important REST question, Chris Hyzer, 03/25/2008
Archive powered by MHonArc 2.6.16.