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

Should GET be used if request has unintended side effects

Expand Messages
  • aakash dharmadhikari
    Hello all, I am developing an API & a consumer for a Yellow Pages like system. I have confusion about two use cases as described below: 1. GET or POST User
    Message 1 of 11 , May 16, 2011
      Hello all,

      I am developing an API & a consumer for a Yellow Pages like system. I have confusion about two use cases as described below:
      1. GET or POST
      User searches for vendors (plumbers) in a given area & sees list of vendors on page. As a requirement, vendors get notified that a user has found him for the search term, so that he can contact the customer.

      The intention of the API user will be to get vendors, so it seems to be a pure GET contender; but the unintended side effect is creation of these notifications. As per the specification, HTTP verb should indicate the intent of the user, but in this case there is a pure object creation. What should we use, POST or GET?

      2. GET or PUT
      Vendor requests for notifications on which he wants to act. I don't want to show him notifications which he has already seen, so while delivering notifications I mark them as delivered. Though the intention is pure retrieval the side effect if object update. Also an aspect of request is to get only unseen notifications, which guarantees that consecutive similar request won't be idempotent. What should I use, GET or PUT?

       Thanks for reading a really long post, I would really appreciate any guidance I can get on it.
      -- 
      
      Regards,
      Aakash Dharmadhikari
      C42 Engineering, http://c42.in/
      
    • algermissen1971
      ... Hmm, that is a tricky question because. GET would be it, because the side effect is an implementation detail. However, you seem to be reaching behind the
      Message 2 of 11 , May 17, 2011


        On 16 May, 2011,at 08:09 PM, aakash dharmadhikari <aakashd@...> wrote:



        Hello all,

        I am developing an API & a consumer for a Yellow Pages like system. I have confusion about two use cases as described below:
        1. GET or POST
        User searches for vendors (plumbers) in a given area & sees list of vendors on page. As a requirement, vendors get notified that a user has found him for the search term, so that he can contact the customer.

        The intention of the API user will be to get vendors, so it seems to be a pure GET contender; but the unintended side effect is creation of these notifications. As per the specification, HTTP verb should indicate the intent of the user, but in this case there is a pure object creation. What should we use, POST or GET?
         
        Hmm, that is a tricky question because. GET would be it, because the side effect is an implementation detail. However, you seem to be reaching behind the user's back here because you distribute her contact details to the vendors.

        Maybe a POST needs to be used with a checkbox where the user can submit her agreement for the notification?

        Jan



        2. GET or PUT
        Vendor requests for notifications on which he wants to act. I don't want to show him notifications which he has already seen, so while delivering notifications I mark them as delivered. Though the intention is pure retrieval the side effect if object update Also an aspect of request is to get only unseen notifications, which guarantees that consecutive similar request won't be idempotent. What should I use, GET or PUT?

         Thanks for reading a really long post, I would really appreciate any guidance I can get on it.
        -- 
        
        Regards,
        Aakash Dharmadhikari
        C42 Engineering, http://c42.in/
        


      • aakash dharmadhikari
        Point taken Norman. The confusion about the GET & POST was caused because of the RFC itself. Broaching a bigger problem, I see that HTTP verbs give more
        Message 3 of 11 , May 17, 2011
          Point taken Norman. The confusion about the GET & POST was caused
          because of the RFC itself.

          Broaching a bigger problem, I see that HTTP verbs give more importance
          to the users intentions & REST talks continuously about server state.
          But when I use HTTP as a carrier for REST requests, I see these
          conflicts all the time.

          Is there a rule of thumb, as to REST always overrides HTTP or the other
          way around?

          About the business scene, user is aware of the sites functioning &
          vendor contacting him is a desired & explicitly communicated effect of
          the search.

          Regards,
          Aakash Dharmadhikari


          On 17/05/11 7:16 PM, Norman Gray wrote:
          > Aakash, hello.
          >
          > On 2011 May 16, at 20:09, aakash dharmadhikari wrote:
          >
          >> 1. GET or POST
          >>
          >> User searches for vendors (plumbers) in a given area& sees list of vendors on page. As a requirement, vendors get notified that a user has found him for the search term, so that he can contact the customer.
          >>
          >> The intention of the API user will be to get vendors, so it seems to be a pure GET contender; but the unintended side effect is creation of these notifications. As per the specification, HTTP verb should indicate the intent of the user, but in this case there is a pure object creation. What should we use, POST or GET?
          > That sounds like you should GET.
          >
          > RFC 2616 section 9.1.1 says of 'idempotent' methods such as GET:
          >
          >> The important
          >> distinction here is that the user did not request the side-effects,
          >> so therefore cannot be held accountable for them.
          > In other words, if your service has server-side side-effects, the HTTP spec says that's your problem, not the user's.
          >
          > Just by the way, if I as a customer were contacted by a merchant when all I'd done was look at their address, I think I'd react poorly. At length, and with gestures. But I presume you know your users.
          >
          > Best wishes,
          >
          > Norman
          >
          >
        • mike amundsen
          FWIW, a good rule of thumb for determining if GET is an appropriate method is to imagine the results of a search bot (e.g. google, yahoo, bing, etc.) making
          Message 4 of 11 , May 17, 2011
            FWIW, a good "rule of thumb" for determining if GET is an appropriate
            method is to imagine the results of a search bot (e.g. google, yahoo,
            bing, etc.) making a request to that link.

            for example, a list of links on a page that look like this:
            GET /my-profile/?action=send-my-email-address-to-everyone
            is something I would *not* want to allow the google-bot to execute

            This is true even if the link looked like this:
            GET /my-profile/
            and the backend process resulted in sending my email address to everyone.

            mca
            http://amundsen.com/blog/
            http://twitter.com@mamund
            http://mamund.com/foaf.rdf#me


            #RESTFest 2010
            http://rest-fest.googlecode.com




            On Tue, May 17, 2011 at 14:29, aakash dharmadhikari <aakashd@...> wrote:
            > Point taken Norman. The confusion about the GET & POST was caused
            > because of the RFC itself.
            >
            > Broaching a bigger problem, I see that HTTP verbs give more importance
            > to the users intentions & REST talks continuously about server state.
            > But when I use HTTP as a carrier for REST requests, I see these
            > conflicts all the time.
            >
            > Is there a rule of thumb, as to REST always overrides HTTP or the other
            > way around?
            >
            > About the business scene, user is aware of the sites functioning &
            > vendor contacting him is a desired & explicitly communicated effect of
            > the search.
            >
            > Regards,
            > Aakash Dharmadhikari
            >
            >
            > On 17/05/11 7:16 PM, Norman Gray wrote:
            >> Aakash, hello.
            >>
            >> On 2011 May 16, at 20:09, aakash dharmadhikari wrote:
            >>
            >>>          1. GET or POST
            >>>
            >>> User searches for vendors (plumbers) in a given area&  sees list of vendors on page. As a requirement, vendors get notified that a user has found him for the search term, so that he can contact the customer.
            >>>
            >>> The intention of the API user will be to get vendors, so it seems to be a pure GET contender; but the unintended side effect is creation of these notifications. As per the specification, HTTP verb should indicate the intent of the user, but in this case there is a pure object creation. What should we use, POST or GET?
            >> That sounds like you should GET.
            >>
            >> RFC 2616 section 9.1.1 says of 'idempotent' methods such as GET:
            >>
            >>> The important
            >>>     distinction here is that the user did not request the side-effects,
            >>>     so therefore cannot be held accountable for them.
            >> In other words, if your service has server-side side-effects, the HTTP spec says that's your problem, not the user's.
            >>
            >> Just by the way, if I as a customer were contacted by a merchant when all I'd done was look at their address, I think I'd react poorly.  At length, and with gestures.  But I presume you know your users.
            >>
            >> Best wishes,
            >>
            >> Norman
            >>
            >>
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
          • aakash dharmadhikari
            Just twisting the scenario a little bit. As a user I make a search request, which results in vendors knowing what I am interested in & they respond with quotes
            Message 5 of 11 , May 17, 2011
              Just twisting the scenario a little bit.

              As a user I make a search request, which results in vendors knowing what
              I am interested in & they respond with quotes for the same. I see those
              quotes on my screen as a small window, which updates itself every 15
              seconds & I can decide which vendor I want to talk to.

              I hope this sounds less scary that all vendors getting my email address.
              But coming back to the point, is any side effect is GET request?

              What about a scenario, where system learns from my interactions with the
              application & because of which it changes its response to suite my
              needs. So any two consecutive requests, though identical, won't be
              idempotent. Should such request be GET or POST or PUT?

              Regards,
              Aakash Dharmadhikari


              On 18/05/11 12:04 AM, mike amundsen wrote:
              > FWIW, a good "rule of thumb" for determining if GET is an appropriate
              > method is to imagine the results of a search bot (e.g. google, yahoo,
              > bing, etc.) making a request to that link.
              >
              > for example, a list of links on a page that look like this:
              > GET /my-profile/?action=send-my-email-address-to-everyone
              > is something I would *not* want to allow the google-bot to execute
              >
              > This is true even if the link looked like this:
              > GET /my-profile/
              > and the backend process resulted in sending my email address to everyone.
              >
              > mca
              > http://amundsen.com/blog/
              > http://twitter.com@mamund
              > http://mamund.com/foaf.rdf#me
              >
              >
              > #RESTFest 2010
              > http://rest-fest.googlecode.com
              >
              >
              >
              >
              > On Tue, May 17, 2011 at 14:29, aakash dharmadhikari<aakashd@...> wrote:
              >> Point taken Norman. The confusion about the GET& POST was caused
              >> because of the RFC itself.
              >>
              >> Broaching a bigger problem, I see that HTTP verbs give more importance
              >> to the users intentions& REST talks continuously about server state.
              >> But when I use HTTP as a carrier for REST requests, I see these
              >> conflicts all the time.
              >>
              >> Is there a rule of thumb, as to REST always overrides HTTP or the other
              >> way around?
              >>
              >> About the business scene, user is aware of the sites functioning&
              >> vendor contacting him is a desired& explicitly communicated effect of
              >> the search.
              >>
              >> Regards,
              >> Aakash Dharmadhikari
              >>
              >>
              >> On 17/05/11 7:16 PM, Norman Gray wrote:
              >>> Aakash, hello.
              >>>
              >>> On 2011 May 16, at 20:09, aakash dharmadhikari wrote:
              >>>
              >>>> 1. GET or POST
              >>>>
              >>>> User searches for vendors (plumbers) in a given area& sees list of vendors on page. As a requirement, vendors get notified that a user has found him for the search term, so that he can contact the customer.
              >>>>
              >>>> The intention of the API user will be to get vendors, so it seems to be a pure GET contender; but the unintended side effect is creation of these notifications. As per the specification, HTTP verb should indicate the intent of the user, but in this case there is a pure object creation. What should we use, POST or GET?
              >>> That sounds like you should GET.
              >>>
              >>> RFC 2616 section 9.1.1 says of 'idempotent' methods such as GET:
              >>>
              >>>> The important
              >>>> distinction here is that the user did not request the side-effects,
              >>>> so therefore cannot be held accountable for them.
              >>> In other words, if your service has server-side side-effects, the HTTP spec says that's your problem, not the user's.
              >>>
              >>> Just by the way, if I as a customer were contacted by a merchant when all I'd done was look at their address, I think I'd react poorly. At length, and with gestures. But I presume you know your users.
              >>>
              >>> Best wishes,
              >>>
              >>> Norman
              >>>
              >>>
              >>
              >> ------------------------------------
              >>
              >> Yahoo! Groups Links
              >>
              >>
              >>
              >>
            • aakash dharmadhikari
              Thanks a lot Steven. I have already changed the system to work like twitter timeline fetch, where client provides the latest notification it has, and asks for
              Message 6 of 11 , May 17, 2011
                Thanks a lot Steven.

                I have already changed the system to work like twitter timeline fetch, where client provides the latest notification it has, and asks for newer ones. This was crucial to solve another issue, that multiple clients with same credentials should get same notifications, as I am not aware of which client end user is in front of. In earlier approach, if an open browser window has already fetched & marked a notification as seen; a mobile client, which vendor is actually using, will never be able to fetch the same notification again.

                But the If-Modified-Since is very clever use of the header, I will certainly try to use it if possible.
                Regards,
                Aakash Dharmadhikari

                On 18/05/11 12:07 AM, Steven Cummings wrote: On Mon, May 16, 2011 at 1:09 PM, aakash dharmadhikari <aakashd@...> wrote:
                2. GET or PUT Vendor requests for notifications on which he wants to act. I don't want to show him notifications which he has already seen, so while delivering notifications I mark them as delivered. Though the intention is pure retrieval the side effect if object update. Also an aspect of request is to get only unseen notifications, which guarantees that consecutive similar request won't be idempotent. What should I use, GET or PUT?


                On this one you could provide the client the ability to specify a date after which notifications would be new or "unread" to that client. This could be achieved either through query parameters to the notification list or If-Modified-Since (conditional GET) on the notification list as a whole resource. In the latter case the list-resource should return a Last-Modified header. This mechanism is intended for cases just like this, I think.

              • mike amundsen
                Aakash: I m not clear on what you are asking here. The only point I was making was to give you a mental exercise for making your own decision on what you
                Message 7 of 11 , May 17, 2011
                  Aakash:

                  I'm not clear on what you are asking here.

                  The only point I was making was to give you a "mental exercise" for
                  making your own decision on what you want your implementation to do. I
                  think you can use the example I gave to view your implementation from
                  both the "user" and "server implementor" point of view. That, I think
                  is the approach you should take.

                  As for your example here, I can't really comment on what is "scary" or
                  "expected" from the users of your implementation. I suspect we all
                  have our own opinions of your description, but I doubt many of us have
                  a proper "context" with which to provide you helpful advice on this
                  particular example.

                  From the transfer protocol point of view, users are not "responsible"
                  for any side effects occurring from a GET as the protocol clearly
                  states that GET should be treated as safe and idempotent. How you
                  choose to implement your server is up to you. As long as it honors
                  this small set of semantic expectations, you'll have met your
                  responsibilities as a server implementer.

                  If it turns out most of your users are unhappy with the side effects
                  of using GET on a particular page, they may come to decide your
                  implementation is undesirable. But those users' opinions of your work
                  will not be due to any prose they find in RFC2616<g>.

                  mca
                  http://amundsen.com/blog/
                  http://twitter.com@mamund
                  http://mamund.com/foaf.rdf#me


                  #RESTFest 2010
                  http://rest-fest.googlecode.com




                  On Tue, May 17, 2011 at 14:42, aakash dharmadhikari <aakashd@...> wrote:
                  > Just twisting the scenario a little bit.
                  >
                  > As a user I make a search request, which results in vendors knowing what I
                  > am interested in & they respond with quotes for the same. I see those quotes
                  > on my screen as a small window, which updates itself every 15 seconds & I
                  > can decide which vendor I want to talk to.
                  >
                  > I hope this sounds less scary that all vendors getting my email address. But
                  > coming back to the point, is any side effect is GET request?
                  >
                  > What about a scenario, where system learns from my interactions with the
                  > application & because of which it changes its response to suite my needs. So
                  > any two consecutive requests, though identical, won't be idempotent. Should
                  > such request be GET or POST or PUT?
                  >
                  > Regards,
                  > Aakash Dharmadhikari
                  >
                  >
                  > On 18/05/11 12:04 AM, mike amundsen wrote:
                  >>
                  >> FWIW, a good "rule of thumb" for determining if GET is an appropriate
                  >> method is to imagine the results of a search bot (e.g. google, yahoo,
                  >> bing, etc.) making a request to that link.
                  >>
                  >> for example, a list of links on a page that look like this:
                  >> GET /my-profile/?action=send-my-email-address-to-everyone
                  >> is something I would *not* want to allow the google-bot to execute
                  >>
                  >> This is true even if the link looked like this:
                  >> GET /my-profile/
                  >> and the backend process resulted in sending my email address to everyone.
                  >>
                  >> mca
                  >> http://amundsen.com/blog/
                  >> http://twitter.com@mamund
                  >> http://mamund.com/foaf.rdf#me
                  >>
                  >>
                  >> #RESTFest 2010
                  >> http://rest-fest.googlecode.com
                  >>
                  >>
                  >>
                  >>
                  >> On Tue, May 17, 2011 at 14:29, aakash dharmadhikari<aakashd@...>
                  >>  wrote:
                  >>>
                  >>> Point taken Norman. The confusion about the GET&  POST was caused
                  >>> because of the RFC itself.
                  >>>
                  >>> Broaching a bigger problem, I see that HTTP verbs give more importance
                  >>> to the users intentions&  REST talks continuously about server state.
                  >>> But when I use HTTP as a carrier for REST requests, I see these
                  >>> conflicts all the time.
                  >>>
                  >>> Is there a rule of thumb, as to REST always overrides HTTP or the other
                  >>> way around?
                  >>>
                  >>> About the business scene, user is aware of the sites functioning&
                  >>> vendor contacting him is a desired&  explicitly communicated effect of
                  >>> the search.
                  >>>
                  >>> Regards,
                  >>> Aakash Dharmadhikari
                  >>>
                  >>>
                  >>> On 17/05/11 7:16 PM, Norman Gray wrote:
                  >>>>
                  >>>> Aakash, hello.
                  >>>>
                  >>>> On 2011 May 16, at 20:09, aakash dharmadhikari wrote:
                  >>>>
                  >>>>>          1. GET or POST
                  >>>>>
                  >>>>> User searches for vendors (plumbers) in a given area&    sees list of
                  >>>>> vendors on page. As a requirement, vendors get notified that a user has
                  >>>>> found him for the search term, so that he can contact the customer.
                  >>>>>
                  >>>>> The intention of the API user will be to get vendors, so it seems to be
                  >>>>> a pure GET contender; but the unintended side effect is creation of these
                  >>>>> notifications. As per the specification, HTTP verb should indicate the
                  >>>>> intent of the user, but in this case there is a pure object creation. What
                  >>>>> should we use, POST or GET?
                  >>>>
                  >>>> That sounds like you should GET.
                  >>>>
                  >>>> RFC 2616 section 9.1.1 says of 'idempotent' methods such as GET:
                  >>>>
                  >>>>> The important
                  >>>>>     distinction here is that the user did not request the side-effects,
                  >>>>>     so therefore cannot be held accountable for them.
                  >>>>
                  >>>> In other words, if your service has server-side side-effects, the HTTP
                  >>>> spec says that's your problem, not the user's.
                  >>>>
                  >>>> Just by the way, if I as a customer were contacted by a merchant when
                  >>>> all I'd done was look at their address, I think I'd react poorly.  At
                  >>>> length, and with gestures.  But I presume you know your users.
                  >>>>
                  >>>> Best wishes,
                  >>>>
                  >>>> Norman
                  >>>>
                  >>>>
                  >>>
                  >>> ------------------------------------
                  >>>
                  >>> Yahoo! Groups Links
                  >>>
                  >>>
                  >>>
                  >>>
                  >
                • aakash dharmadhikari
                  I think in my failed attempt to address two issues, I created more confusion that clarity. 1. Unfortunately, due to clients NDA, I can t explain complete work
                  Message 8 of 11 , May 17, 2011
                    I think in my failed attempt to address two issues, I created more
                    confusion that clarity.

                    1. Unfortunately, due to clients NDA, I can't explain complete work flow
                    which caused the misunderstanding. From overall mails I saw people
                    digressing from core problem due to the "email sharing" assumption. In
                    order to get an unbiased opinion I wanted to pose a different use case.
                    That's where the "non scary" part come in.

                    2. I have gone through the RFC2616 & some resources for REST; just to
                    find that HTTP talks about user's intention & REST talks about server
                    state. When we use both of them together, there is a lot of confusion
                    about which prevails over the other.

                    3. About the last hypothetical scenario of search, should a fetch
                    request with an unintentional side effect be treated as PUT or POST or
                    PARTIAL?

                    Regards,
                    Aakash Dharmadhikari


                    On 18/05/11 12:23 AM, mike amundsen wrote:
                    > Aakash:
                    >
                    > I'm not clear on what you are asking here.
                    >
                    > The only point I was making was to give you a "mental exercise" for
                    > making your own decision on what you want your implementation to do. I
                    > think you can use the example I gave to view your implementation from
                    > both the "user" and "server implementor" point of view. That, I think
                    > is the approach you should take.
                    >
                    > As for your example here, I can't really comment on what is "scary" or
                    > "expected" from the users of your implementation. I suspect we all
                    > have our own opinions of your description, but I doubt many of us have
                    > a proper "context" with which to provide you helpful advice on this
                    > particular example.
                    >
                    > From the transfer protocol point of view, users are not "responsible"
                    > for any side effects occurring from a GET as the protocol clearly
                    > states that GET should be treated as safe and idempotent. How you
                    > choose to implement your server is up to you. As long as it honors
                    > this small set of semantic expectations, you'll have met your
                    > responsibilities as a server implementer.
                    >
                    > If it turns out most of your users are unhappy with the side effects
                    > of using GET on a particular page, they may come to decide your
                    > implementation is undesirable. But those users' opinions of your work
                    > will not be due to any prose they find in RFC2616<g>.
                    >
                    > mca
                    > http://amundsen.com/blog/
                    > http://twitter.com@mamund
                    > http://mamund.com/foaf.rdf#me
                    >
                    >
                    > #RESTFest 2010
                    > http://rest-fest.googlecode.com
                    >
                    >
                    >
                    >
                    > On Tue, May 17, 2011 at 14:42, aakash dharmadhikari<aakashd@...> wrote:
                    >> Just twisting the scenario a little bit.
                    >>
                    >> As a user I make a search request, which results in vendors knowing what I
                    >> am interested in& they respond with quotes for the same. I see those quotes
                    >> on my screen as a small window, which updates itself every 15 seconds& I
                    >> can decide which vendor I want to talk to.
                    >>
                    >> I hope this sounds less scary that all vendors getting my email address. But
                    >> coming back to the point, is any side effect is GET request?
                    >>
                    >> What about a scenario, where system learns from my interactions with the
                    >> application& because of which it changes its response to suite my needs. So
                    >> any two consecutive requests, though identical, won't be idempotent. Should
                    >> such request be GET or POST or PUT?
                    >>
                    >> Regards,
                    >> Aakash Dharmadhikari
                    >>
                    >>
                    >> On 18/05/11 12:04 AM, mike amundsen wrote:
                    >>> FWIW, a good "rule of thumb" for determining if GET is an appropriate
                    >>> method is to imagine the results of a search bot (e.g. google, yahoo,
                    >>> bing, etc.) making a request to that link.
                    >>>
                    >>> for example, a list of links on a page that look like this:
                    >>> GET /my-profile/?action=send-my-email-address-to-everyone
                    >>> is something I would *not* want to allow the google-bot to execute
                    >>>
                    >>> This is true even if the link looked like this:
                    >>> GET /my-profile/
                    >>> and the backend process resulted in sending my email address to everyone.
                    >>>
                    >>> mca
                    >>> http://amundsen.com/blog/
                    >>> http://twitter.com@mamund
                    >>> http://mamund.com/foaf.rdf#me
                    >>>
                    >>>
                    >>> #RESTFest 2010
                    >>> http://rest-fest.googlecode.com
                    >>>
                    >>>
                    >>>
                    >>>
                    >>> On Tue, May 17, 2011 at 14:29, aakash dharmadhikari<aakashd@...>
                    >>> wrote:
                    >>>> Point taken Norman. The confusion about the GET& POST was caused
                    >>>> because of the RFC itself.
                    >>>>
                    >>>> Broaching a bigger problem, I see that HTTP verbs give more importance
                    >>>> to the users intentions& REST talks continuously about server state.
                    >>>> But when I use HTTP as a carrier for REST requests, I see these
                    >>>> conflicts all the time.
                    >>>>
                    >>>> Is there a rule of thumb, as to REST always overrides HTTP or the other
                    >>>> way around?
                    >>>>
                    >>>> About the business scene, user is aware of the sites functioning&
                    >>>> vendor contacting him is a desired& explicitly communicated effect of
                    >>>> the search.
                    >>>>
                    >>>> Regards,
                    >>>> Aakash Dharmadhikari
                    >>>>
                    >>>>
                    >>>> On 17/05/11 7:16 PM, Norman Gray wrote:
                    >>>>> Aakash, hello.
                    >>>>>
                    >>>>> On 2011 May 16, at 20:09, aakash dharmadhikari wrote:
                    >>>>>
                    >>>>>> 1. GET or POST
                    >>>>>>
                    >>>>>> User searches for vendors (plumbers) in a given area& sees list of
                    >>>>>> vendors on page. As a requirement, vendors get notified that a user has
                    >>>>>> found him for the search term, so that he can contact the customer.
                    >>>>>>
                    >>>>>> The intention of the API user will be to get vendors, so it seems to be
                    >>>>>> a pure GET contender; but the unintended side effect is creation of these
                    >>>>>> notifications. As per the specification, HTTP verb should indicate the
                    >>>>>> intent of the user, but in this case there is a pure object creation. What
                    >>>>>> should we use, POST or GET?
                    >>>>> That sounds like you should GET.
                    >>>>>
                    >>>>> RFC 2616 section 9.1.1 says of 'idempotent' methods such as GET:
                    >>>>>
                    >>>>>> The important
                    >>>>>> distinction here is that the user did not request the side-effects,
                    >>>>>> so therefore cannot be held accountable for them.
                    >>>>> In other words, if your service has server-side side-effects, the HTTP
                    >>>>> spec says that's your problem, not the user's.
                    >>>>>
                    >>>>> Just by the way, if I as a customer were contacted by a merchant when
                    >>>>> all I'd done was look at their address, I think I'd react poorly. At
                    >>>>> length, and with gestures. But I presume you know your users.
                    >>>>>
                    >>>>> Best wishes,
                    >>>>>
                    >>>>> Norman
                    >>>>>
                    >>>>>
                    >>>> ------------------------------------
                    >>>>
                    >>>> Yahoo! Groups Links
                    >>>>
                    >>>>
                    >>>>
                    >>>>
                  • Jon Hanna
                    ... Prevail when? This is the same thing. If it s the user s intention to change server state, then it should be a method other than GET or HEAD. If it isn t
                    Message 9 of 11 , May 18, 2011
                      On 2011-05-18 05:00, aakash dharmadhikari wrote:
                      > 2. I have gone through the RFC2616& some resources for REST; just to
                      > find that HTTP talks about user's intention& REST talks about server
                      > state. When we use both of them together, there is a lot of confusion
                      > about which prevails over the other.

                      Prevail when? This is the same thing. If it's the user's intention to
                      change server state, then it should be a method other than GET or HEAD.
                      If it isn't the user's intention to change server state, then it
                      shouldn't be.

                      There's only a conflict when something happens counter to the user's
                      intention, which is a good working definition of "bug".
                    • Will Hartung
                      ... There is no conflict here. REST is REST. HTTP is HTTP. REST != HTTP. There are many, unRESTful properties to HTTP and ways to use HTTP in an unRESTful
                      Message 10 of 11 , May 18, 2011
                        On Tue, May 17, 2011 at 9:00 PM, aakash dharmadhikari <aakashd@...> wrote:
                        2. I have gone through the RFC2616 & some resources for REST; just to

                        find that HTTP talks about user's intention & REST talks about server
                        state. When we use both of them together, there is a lot of confusion
                        about which prevails over the other.


                        There is no "conflict" here. REST is REST. HTTP is HTTP. REST != HTTP. There are many, unRESTful properties to HTTP and ways to use HTTP in an unRESTful manner.

                        If you wish to build a REST system on top of HTTP, then you need to constrain your use of HTTP so that it stays within the boundaries of a REST architecture.

                        Also, there are several examples of resources that use GET but do not return the same payload each time.

                        GET /current_temperature
                        GET /random_number
                        GET /new_items

                        The premise is that you are not using GET to change state. If state changes on the server, then that's the servers problem. That's an issue for the developer of the service, but it doesn't change the contract for the client.

                        If GET /new_items returns a list of items and then you call it again and get an empty list (because the server implementation feels that since it served the items up once, then the items are no longer "new"), well that's the server's problem. Not the clients.

                        You do GET /new_items, and you got all of the "new items". You didn't call GET /new_items to change the state of the items from "new" to "not new", you called it to get "new items" using whatever criteria the server set for "new-ness", in contrast to whatever your definition of "new-ness" is. It's the servers resource, not yours. It could give you the same or growing list all day long and reset abruptly at 12am.

                        Now, you can question the wisdom of the server implementation, but that's a different discussion.

                        Regards,

                        Will Hartung
                        (willh@...)



                      • aakash dharmadhikari
                        Thanks Will, In this approach, the GET request does not remain idempotent and it changes the state of the system (unintentional side effect); but that s
                        Message 11 of 11 , May 18, 2011
                          Thanks Will,

                          In this approach, the GET request does not remain idempotent and it changes the state of the system (unintentional side effect); but that's perfectly fine as we are not only restricting certain HTTP rules even twisting others to fit the REST way. The resource here is new_items, by whatever definition server chooses to believe.

                          This is pretty much what I thought as well, except I was not sure if this was the right way to look at things. Thanks again.
                          Regards,
                          Aakash Dharmadhikari
                          http://c42.in/
                          

                          On 18/05/11 11:24 PM, Will Hartung wrote:  



                          On Tue, May 17, 2011 at 9:00 PM, aakash dharmadhikari <aakashd@...> wrote:
                          2. I have gone through the RFC2616 & some resources for REST; just to

                          find that HTTP talks about user's intention & REST talks about server
                          state. When we use both of them together, there is a lot of confusion
                          about which prevails over the other.


                          There is no "conflict" here. REST is REST. HTTP is HTTP. REST != HTTP. There are many, unRESTful properties to HTTP and ways to use HTTP in an unRESTful manner.

                          If you wish to build a REST system on top of HTTP, then you need to constrain your use of HTTP so that it stays within the boundaries of a REST architecture.

                          Also, there are several examples of resources that use GET but do not return the same payload each time.

                          GET /current_temperature
                          GET /random_number
                          GET /new_items

                          The premise is that you are not using GET to change state. If state changes on the server, then that's the servers problem. That's an issue for the developer of the service, but it doesn't change the contract for the client.

                          If GET /new_items returns a list of items and then you call it again and get an empty list (because the server implementation feels that since it served the items up once, then the items are no longer "new"), well that's the server's problem. Not the clients.

                          You do GET /new_items, and you got all of the "new items". You didn't call GET /new_items to change the state of the items from "new" to "not new", you called it to get "new items" using whatever criteria the server set for "new-ness", in contrast to whatever your definition of "new-ness" is. It's the servers resource, not yours. It could give you the same or growing list all day long and reset abruptly at 12am.

                          Now, you can question the wisdom of the server implementation, but that's a different discussion.

                          Regards,

                          Will Hartung
                          (willh@...)



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