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

Re: REST: The short version

Expand Messages
  • wahbedahbe
    Hmmm I don t think we are that far off... ... think I have ... Agreed. That is what I meant when I said and usually navigate to that state in one step . When
    Message 1 of 10 , Jun 1, 2008
    View Source
    • 0 Attachment
      Hmmm I don't think we are that far off...


      > I didn't get such a different reading from Mike's article, but I
      think I have
      > a different view of the Hypermedia constraint¹ than you do…
      >
      > The client doesn't only execute GETs to transition between states, POSTs
      > transition between states just as well.

      Agreed. That is what I meant when I said "and usually navigate to that
      state in one step". When you are looking at things from a state
      machine perspective, POST is often like a request that says "Please
      add the state described in the body and transition me to that new
      state". Though its not necessarily always like that I suppose. It
      could perhaps be generalized to something like this: "Please change
      the state machine as described in the body and transition me to the
      state that represents my changes"?

      >
      > The client doesn't *change* the state machine, per se … it merely
      transitions
      > between the states allowed by the server, as described by the
      hypermedia.
      > Those transitions might end up mutating the state machine, but
      that's not the
      > same as the client mutating the state machine.
      >

      So I agree that the server is changing the state machine in response
      to the requests from the client. The client can't directly change the
      state machine (i.e. the resources) -- it has to ask the server to do
      it on its behalf. The requests made by the clients effect the changes
      to the resources/state machine performed by the server (though of
      course resources could change for other reasons -- e.g. a resource
      that represents the weather in New York).

      Was I missing something other than the server being involved though?


      >
      > ¹: I think "HATEOAS" is a bad name. "Hypermedia constraint" is more
      > descriptive, and less "HATE"-filled. :)
      >

      Ya, HATEOAS is a mouth-full... but I think the "engine" and
      "application state" parts are important as well. I think they
      represent specific areas where attempts at REST tend to fall short.
    • Josh Sled
      ... […] ... No, I don t think so. ... Oh, certainly they re important, and I d strongly agree that many visible REST APIs are woefully insufficient with
      Message 2 of 10 , Jun 1, 2008
      View Source
      • 0 Attachment
        "wahbedahbe" <andrew.wahbe@...> writes:
        > Hmmm I don't think we are that far off...
        […]
        > Was I missing something other than the server being involved though?

        No, I don't think so.

        >> ¹: I think "HATEOAS" is a bad name. "Hypermedia constraint" is more
        >> descriptive, and less "HATE"-filled. :)
        >>
        >
        > Ya, HATEOAS is a mouth-full... but I think the "engine" and
        > "application state" parts are important as well. I think they
        > represent specific areas where attempts at REST tend to fall short.

        Oh, certainly they're important, and I'd strongly agree that many visible
        "REST" APIs are woefully insufficient with respect to hypermedia.

        But we often don't include all the details of a thing in its name. Simply as
        a name, HATEOAS is just bad, imho.

        --
        ...jsled
        http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}
      Your message has been successfully submitted and would be delivered to recipients shortly.