Re: 202 Response to GET request

No argument from me :-)


On Sun, Oct 6, 2013 at 10:01 PM, Unmesh Joshi <[email protected]> wrote:

> There are three things to consider.
>
> First, What is the reason for which 202 status code is added in HTTP?
>
> "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."
>
> Accepting the request for other process, most times wont be a GET.  If
> its modeled as a GET, the modelling of the HTTP GET handler on the server
> becomes non trivial, and extra care needs to be taken to make sure the
> handling is idempotent and safe. (e.g. multiple requests for the same
> resource are not causing multiple entries in queue to generate the
> resource).
>
> 202 response is generally used for making operations asynchronous if the
> resource construction  is too slow. e.g. if /search is too slow (not
> returning in say 5 minutes), because of resource constraints on the server
> side (whatever they might be).
> In these cases, by design, a new request resource is created on the server
> which is handled by a scheduled process.
>
> Using GET in these cases, seems wrong, from modelling point of view.
>
> Second thing to consider is if its valid according to HTTP standard to
> return 202 response code for a GET request.
> The answer is yes, as HTTP standard, does not put any constraint on the
> response codes returned for GET.
>
> Third thing to consider is, whats is the accepted idiom used for such
> designs in the community.  Some examples out there
> https://www.tbray.org/ongoing/When/200x/2009/07/02/Slow-REST and also
> http://www.amazon.com/REST-Practice-Hypermedia-Systems-Architecture/dp/0596805829.
> seem to suggest its POST - 202 polling, as an idiom that's generally used.
>
>  Thanks,
> Unmesh
>
> Thanks,
> Unmesh
>
>
>
>
>
>
> On Mon, Oct 7, 2013 at 12:10 AM, Glenn Block <[email protected]>wrote:
>
>> Yes I understand the GET is safe. My question / point, is 202 valid for a
>> safe method that is doing no work?
>>
>>
>> On Sun, Oct 6, 2013 at 11:34 AM, Jan Algermissen <
>> [email protected]> wrote:
>>
>>>
>>> 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
>>> > > >
>>> > > >
>>> > > >
>>> > >
>>> >
>>> >
>>> > 
>>>
>>>
>>
>