Re: 202 Response to GET request

On 05.10.2013, at 20:15, Glenn Block <[email protected]> wrote:

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

Hmm, yes. But I meant that the GET on the PDF-URI is still idempotent and safe from the POV of the client ... even if the first GET starts the generation and returns a 202.

However, it was all just a remark in what case you *might* maybe uses a 202 for a GET :-)

Jan

> 
> On Saturday, October 5, 2013, Jan Algermissen wrote:
> 
> 
> On 05.10.2013, at 20:01, Glenn Block <[email protected]> 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]> 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
> > >
> > >
> > > 
> >
> 
> 
> 



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://info.yahoo.com/legal/us/yahoo/utos/terms/