Re: 202 Response to GET request

Yes on querying the resource but isn't that the entire reason for returning
the monitor uri? ie 'go here to check the status' ?

On Saturday, October 5, 2013, Jan Algermissen wrote:

>
> On 05.10.2013, at 20:01, Glenn Block <[email protected] <javascript:;>>
> wrote:
>
> > Hmm, you are suggesting it is valid, I read as relating to an unsafe
> method ie that performs some work.
>
> Yes - that is why I wrote 'Maybe' :-) However, the GET would still be
> idempotent and safe - the client can safely call the GET on the pdf URL as
> often as it wants and the fact that a background process has been started
> for the first GET is not of concern to the client.
>
> All that with some caveat, I am not sure I'll agree with this in a couple
> of hours :-)
>
> Jan
>
>
> > GET is always safe, I agree querying for a status is not causing a side
> effect but still.
> >
> > On Saturday, October 5, 2013, Jan Algermissen wrote:
> >
> > On 05.10.2013, at 19:21, Glenn Block <[email protected]<javascript:;>>
> wrote:
> >
> > > Seems very odd for the reasons you cited, 202 says your request has
> not been processes. The spec also speaks about the location uri pointing to
> a monitor. I would not expect the status code of that monitor to be a 202
> either.
> >
> > No, that resource provides you with information about the status of the
> processing of the other request.
> >
> >
> > Maybe:
> >
> > GET /account/jim/downloads/someLargeBoolAsPdf.pdf
> >
> > 202 Accepted
> > Location: /account/jim/downloads
> > Content-Type: text/plain
> >
> > Thank you for requesting this download - you PDF is being created.
> Please visit your downloads overview page to check the status of the PDF
> generation.
> >
> >
> >
> > Jan
> >
> >
> >
> > >
> > >
> > > On Saturday, October 5, 2013, Unmesh Joshi wrote:
> > >
> > >
> > > Hi,
> > >
> > > I recently came across an API which was returning '202 Accepted'
> response to GET request. It seemed a bit odd.
> > > Most asynchronous operations on HTTP implemented with POST request and
> 202 response.
> > > While HTTP does not mandate 202 response to be returned only to POST
> requests, following lines in RFC do indicate, its almost always going to
> POST.
> > >
> > > "The 202 response is intentionally non-committal. Its purpose is to
> allow a server to accept a request for some other process. (perhaps a
> batch-oriented process that is only run once per day) without requiring
> that the user agent's connection to the server persist until the process is
> completed. "
> > >
> > > Have anyone come across implementations using 202 response for GET?
> > >
> > > Thanks,
> > > Unmesh
> > >
> > >
> > > 
> >
>
>