On Jan 29, 2008, at 6:23 AM, Stephan Koops wrote:
>
> Why must the status code be 202 (Accpeted), if a resource method
> returns any other than void or Reponse?
Thanks for spotting this. I intended to write 200 but somewhere
between my brain and fingers is got transposed to 202. I'll fix it now.
> I think this change throw away the advantage of the possibility to
> return an object that not is a response. I think it is useful to
> have different status codes for different HTTP methods:
> • For GET (and HEAD) I think 200 (OK) is the better status code,
> because that is the typical status code for this HTTP methods.
Agreed.
> • For POST I think it is better to return status code 201 (Created)
> by default. If the resource method returns an URI, this could be
> mapped to the location header.
I think I'd rather stick with a default of 200 for POST since you
really need to return a Location with a 201 response. I don't really
like the idea of specializing the return of URI to map that to a
location header.
>
> • To ease the development of web application you have the
> possibility to specify to return 303 (see other) when the request
> was send by a browser and an URI was returned (redirect after post
> pattern). To identify that the request was send by a browser I
> suggest @ProduceMime("text/html") on the resource method. Perhaps it
> is useful to require also (or perhaps only)
> @ConsumeMime("application/x-www-form-urlencoded").
I'd prefer to leave this up to the developer of the web app and not
specialize this in the spec.
> • For DELETE and PUT I suggest 200 (OK) if the resource method
> returned an object as entity or 204 (no content) if null was
> returned, like the case void.
Yes, specializing for null might be a good idea since we can't
identify a message body writer without an object. I think I'd extend
that behavior to GET and POST also.
>
> Of course this is all possible by use the static methods of
> Response, but the intention of the JSR 311 specification is to make
> this things as easy as possible.
> On the other hand the specification will grow, but I think it's not
> a big thing here.
>
> In general the clarification was good.
>
> BTW: I think it is good to add a comment to Response.seeOther(URI)
> that this method should be used to use the redirect after post
> pattern.
>
OK. I'll do that.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.