Well, I guess generally the 202 is used more for PUT/POST/DELETE
operations. Basically, it is informing the client to close the
connection and not wait for a different response because doing so would
tie up the line. Included in the response should be some indication of
how long a client should wait.
If you accept the Webdav extensions into your application, the 102 seems
appropriate (to me anyway). It's saying that the resource at the
specified location is correct but yet to be updated. Ie. it's related
more to a GET operation.
If you don't accept Webdav, then I think you're right. You would want
to do something along with using 202 with the GET. I don't think the
http spec is too detailed about its use, nor asynchronous connections in
general. So, it's somewhat going in mostly uncharted and/or rarely used
territory as it is.
I guess it's how HTTP compliant you want to be and whether not you can
use the Webdav HTTP extensions. In my opinion, Webdav is perfectly fine
to use, since it's pretty much established defacto standard. But, if
your service uses web browser as a client (like his does), then there
may be issues and coming up with a HTTP only solution might be better.
Anyway, good point.
Avi Flax wrote:
On 7/18/07, Adam Taft <[EMAIL PROTECTED]> wrote:
I like the webdav status code use, 102 Processing. Seems very
appropriate.
Sorry to come into this late, but this caught my eye. If this is a
RESTful web service, wouldn't HTTP's "202 Accepted" be a more
appropriate Response Code for asynchronous processing?
Avi
