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

Re: [rest-discuss] Should GET be used if request has unintended side effects

Expand Messages
  • 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 1 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 2 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.