Rob,
Do you have any metric that points to which browsers do or do not
support a 201 Created status / Location header combination? I'd be
interested in knowing as I'm having a hard time finding a definitive
answer to this question.
Regardless of client method, my experience has been this
I apologize for being dusty.
I just gave it a try on several user agents and 201 Created worked fine. I
did have problems with it in the past, but the past is, well, past. :-)
- Rob
Well, like I said, I don't do broad testing or anything, so I honestly
didn't know. It's just more my gut feeling that this works acceptably.
I agree, it definitely didn't work back in the good old days! ;)
Adam
p.s. thanks for the continued play on words. my wife: what are you
In the case you give, I would use a redirect, with Response.redirectOther as
described in http://permalink.gmane.org/gmane.comp.java.restlet/2971 -- for
exactly the reason Stephan describes. This is established practice as
codified in the HTTP RFCs, and ensures that any random well-behaved user
The sense the redirection after POST is to clean the browser cache from
POST requests to avoid a resend this call again when running threw the
history with the back and forward buttons. If you implement for a
browser, than you should send a redirect. If you implementing only as
web service,
The POST is creating a new resource in the persistence layer, then
returning, as text, the URL to that new resource. It just strikes me
that returning the textual representation of the URL is a GET operation
and should be treated as such, no? Redirecting and writing to the
Response both
I think, before I made any sound observations, I'd want to know more about
your use case and what functional effects are exposed by this particular
POST.
In general, there's nothing illicit about POST returning either a meaningful
representation, or a redirect. Either of these are the two most
7 matches
Mail list logo
