Loading ...
Sorry, an error occurred while loading the content.

202 Response to GET request

Expand Messages
  • Unmesh Joshi
    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
    Message 1 of 11 , Oct 5, 2013
    • 0 Attachment
      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
    • Glenn Block
      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
      Message 2 of 11 , Oct 5, 2013
      • 0 Attachment
        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.

        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

      • Jan Algermissen
        ... No, that resource provides you with information about the status of the processing of the other request. Maybe: GET
        Message 3 of 11 , Oct 5, 2013
        • 0 Attachment
          On 05.10.2013, at 19:21, Glenn Block <glenn.block@...> 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
          >
          >
          >
        • Glenn Block
          Hmm, you are suggesting it is valid, I read as relating to an unsafe method ie that performs some work. GET is always safe, I agree querying for a status is
          Message 4 of 11 , Oct 5, 2013
          • 0 Attachment
            Hmm, you are suggesting it is valid, I read as relating to an unsafe method ie that performs some work. 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 <glenn.block@...> 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
            >
            >
            >

          • Jan Algermissen
            ... 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
            Message 5 of 11 , Oct 5, 2013
            • 0 Attachment
              On 05.10.2013, at 20:01, Glenn Block <glenn.block@...> 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 <glenn.block@...> 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
              > >
              > >
              > >
              >
            • Glenn Block
              Yes on querying the resource but isn t that the entire reason for returning the monitor uri? ie go here to check the status ?
              Message 6 of 11 , Oct 5, 2013
              • 0 Attachment
                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 <glenn.block@...> 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 <glenn.block@...> 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
                > >
                > >
                > >
                >

              • Eric J. Bowman
                ... I don t want to rule out a 202 response to a GET, but if the response is the same as one would expect to receive with a 200 then it s a borked server.
                Message 7 of 11 , Oct 5, 2013
                • 0 Attachment
                  Unmesh Joshi wrote:
                  >
                  > I recently came across an API which was returning '202 Accepted'
                  > response to GET request. It seemed a bit odd.
                  >

                  I don't want to rule out a 202 response to a GET, but if the response
                  is the same as one would expect to receive with a 200 then it's a
                  borked server. Without going into details, a 200 should be a 200,
                  plain and simple.

                  -Eric
                • Jan Algermissen
                  ... 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
                  Message 8 of 11 , Oct 6, 2013
                  • 0 Attachment
                    On 05.10.2013, at 20:15, Glenn Block <glenn.block@...> 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 <glenn.block@...> 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 <glenn.block@...> 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
                    > > >
                    > > >
                    > > >
                    > >
                    >
                    >
                    >
                  • Glenn Block
                    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
                    Message 9 of 11 , Oct 6, 2013
                    • 0 Attachment
                      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 <jan.algermissen@...> wrote:

                      On 05.10.2013, at 20:15, Glenn Block <glenn.block@...> 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 <glenn.block@...> 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 <glenn.block@...> 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
                      > > >
                      > > >
                      > > >
                      > >
                      >
                      >
                      >


                    • Unmesh Joshi
                      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
                      Message 10 of 11 , Oct 6, 2013
                      • 0 Attachment
                        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

                         Thanks,
                        Unmesh

                        Thanks,
                        Unmesh






                        On Mon, Oct 7, 2013 at 12:10 AM, Glenn Block <glenn.block@...> 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 <jan.algermissen@...> wrote:

                        On 05.10.2013, at 20:15, Glenn Block <glenn.block@...> 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 <glenn.block@...> 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 <glenn.block@...> 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
                        > > >
                        > > >
                        > > >
                        > >
                        >
                        >
                        >



                      • Glenn Block
                        No argument from me :-)
                        Message 11 of 11 , Oct 6, 2013
                        • 0 Attachment
                          No argument from me :-)


                          On Sun, Oct 6, 2013 at 10:01 PM, Unmesh Joshi <unmeshjoshi@...> 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

                           Thanks,
                          Unmesh

                          Thanks,
                          Unmesh






                          On Mon, Oct 7, 2013 at 12:10 AM, Glenn Block <glenn.block@...> 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 <jan.algermissen@...> wrote:

                          On 05.10.2013, at 20:15, Glenn Block <glenn.block@...> 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 <glenn.block@...> 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 <glenn.block@...> 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
                          > > >
                          > > >
                          > > >
                          > >
                          >
                          >
                          >




                        Your message has been successfully submitted and would be delivered to recipients shortly.