- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 26 Aug 2011 13:47:19 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2011-08-26 10:03, Mark Nottingham wrote: > > On 26/08/2011, at 5:48 PM, Julian Reschke wrote: > >>>> ...so a "status monitor" resource would also be a candidate for the Location header field. >>> >>> If it could be either, I think that would be bad for interop; you wouldn't be sure what following the location would result in. >> >> Right. I'm just not sure which of these makes more sense, so before picking one we probably should look at existing usage. > > My thinking was that Location has a defined semantic in a 201, and arguably 202 should follow the same pattern. > ... Yes, if it makes sense and matches what people do :-) I had a look at the first entry from Alexandre's list: http://escience.washington.edu/what-we-do/sqlshare-rest-api ...and it does something interesting. The initial 202 comes with a Location header field; the identified resource acts both as monitor and final result (202 -> you need to poll again, 200 -> here's your result). I currently do not have time to check the other examples, but we really should before putting something into the spec... Best regards, Julian
Received on Friday, 26 August 2011 11:47:59 UTC