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

REST and DELETE?

Expand Messages
  • Dan Stromberg
    There s something I m not getting about REST. We re supposed to use HTTP verbs like GET, PUT, POST and DELETE. But we re also supposed to be avoiding server
    Message 1 of 31 , Aug 8, 2012

      There's something I'm not getting about REST.

      We're supposed to use HTTP verbs like GET, PUT, POST and DELETE.

      But we're also supposed to be avoiding server state, like sessions.

      How can we have a stateless protocol (that is, a protocol in which all state is saved in the client, using the REST hierarchy as a sort of state machine), that supports a DELETE operation?

      Are some HTTP verbs more RESTful than others?  It seems like PUT, POST and DELETE are all about storing state on the server.

      Thanks!

    • Jan Algermissen
      ... The state of the resource can change between T1 when the client looks at the representation and T2 when the POST is received. How would you ever detect a
      Message 31 of 31 , Aug 25, 2012
        On Aug 25, 2012, at 4:27 AM, Darrel Miller wrote:

        > Jan,
        >
        > On Fri, Aug 24, 2012 at 6:50 PM, Jan Algermissen
        > <jan.algermissen@...> wrote:
        > >
        > > Think about it this way:
        > >
        > > Because REST explicitly allows the server to independently change at any time, the messages sent by the client must be 'designed' to allow the server to detect any mismatch between the client's intent and what the server is about to do as a result of the request.
        > >
        >
        > I appreciate the fact that you are trying to address the impact of
        > sending messages that are not self-description. However, I still
        > don't see how how embedding content versus referring to an existing
        > resource makes the message any more robust in capturing the users
        > intent.

        The state of the resource can change between T1 when the client looks at the representation and T2 when the POST is received. How would you ever detect a mismatch?

        When you, e.g. place an order, you send an order document with the details you intend the business transaction to be like (items + price). You'd rather not simply refer to some recipient-owned conversational state.

        Thinking about it, I guess the real explanation is that the server-side state we are talking about e.g. the cart, is state the client has built up while proceeding through the application (Roy called this workspace state a while ago). In the discussed scenarios we are talking about workspace state that is persistet on the server. Doing so is RESTful (because the state has a URI instead of being session state) but since it is workspace state you should obtain its current representation first and include that in your POST instead of referring to it.

        Does that help?

        Another thing to consider is that HTTP (not REST[1]) is restricted to a single request target URI[2]. Referring to the, e.g. cart URI, smells like two request target URIs to me: tell the server to GET the cart and apply it's state to the POST execution.

        Jan


        [1] In fact, IIRC Roy has multiple request target URIs on his wish list for WAKA
        [2] This is the reason, you cannot implement a RESTful COPY with HTTP





        > I can imagine scenarios where the user explicitly wants to
        > refer to a time varying resource. Embedding a representation of that
        > resource would result in a loss of fidelity of the message.
        >
        > >
        > > IOW, the semantics of the message (the deducable intended effect) must, under no cicumstances, be dependent on the nature of the recipient.
        > >
        >
        > I am really struggling to grasp this concept. You seem to be saying
        > that a self-descriptive message must be deterministic, which seems
        > impossible unless resource state was read-only.
        >
        > I must be mis-intepreting you.
        >
        > Darrel
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.