Re: Returning from a POST
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 has worked fine for me on newer browsers (probably since FF 1.0 and IE 5. maybe since decent XmlHttpRequest support has existed?). Granted, I don't test wide across very many browsers. I am under the assumption that the super majority of user agents support this, and to downgrade, one could always specify a message body in the response (like a one line click here URL, or a quick javascript redirect). To discourage people from using 201 Created with a Location header is, well, discouraging. Adam Rob Heittman wrote: Yes, except many user agents only understand 201 Created in response to a PUT, not a POST. Again, a lot depends on whether the server facility is being written for general browsers or a specific client. The Location header is also used in the 303 See Other response. On 12/10/07, Ben [EMAIL PROTECTED] wrote: Isn't this where the Location HTTP header should be used, to indicate the URL of the new resource?
Re: Returning from a POST
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
Re: Returning from a POST
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 laughing at?!? :) Rob Heittman wrote: 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
Re: Returning from a POST
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 agent will do the right thing. But if you are writing your own client or otherwise control the clients behavior completely, of course you can selectively ignore such practices in favor of greater efficiency. - R
Re: Returning from a POST
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, than you don't use the redirect, IMO Stephan
Re: Returning from a POST
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 address my needs, but I don't want to issue a redirect per se. Thinking it through now, I'd say continuing to write to the response is the most appropriate way. Thank you, - Dustin Rob Heittman wrote: 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 common choices. I don't think the concept of forwarding maps especially well on to the REST style, since it is all about internally returning the representation of a resource other than the one addressed by the client. You can achieve it in Restlet by executing a client operation inside your POSTable resource (and in Restlet 1.1 you can use the addressable server router on the Component to do this efficiently), but it looks exactly like the sleight of hand it is. - Rob -- Dustin N. Jenkins | Tel/Tél: 250.363.3101 | [EMAIL PROTECTED] facsimile/télécopieur: (250) 363-0045 National Research Council Canada | 5071 West Saanich Rd, Victoria BC. V9E 2E7 Conseil national de recherches Canada | 5071, ch. West Saanich, Victoria (C.-B) V9E 2E7 Government of Canada | Gouvernement du Canada
Re: Returning from a POST
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 common choices. I don't think the concept of forwarding maps especially well on to the REST style, since it is all about internally returning the representation of a resource other than the one addressed by the client. You can achieve it in Restlet by executing a client operation inside your POSTable resource (and in Restlet 1.1 you can use the addressable server router on the Component to do this efficiently), but it looks exactly like the sleight of hand it is. - Rob
