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

RE: [rest-discuss] How much REST should your Web API get?

Expand Messages
  • Markus Lanthaler
    ... That has nothing to do with statelessness as it describes what the client is doing. The request to the server definitely contains all information and
    Message 1 of 46 , May 4 9:47 AM
    • 0 Attachment
      On Saturday, May 04, 2013 5:54 PM, Mike Schinkel wrote:
      > On May 4, 2013, at 9:35 AM, Jørn Wildt <jw@...> wrote:
      > > Allow me to disagree with you here. Why do you consider this as
      > > being stateful? I don't see how this has anything to do with it.
      >
      > Unless everything in your API can be done with at most two HTTP
      > requests (I had not considered that potential) then it would seem your
      > 3rd HTTP request would be assuming the state of your 1st request and
      > thus your API not RESTful. If not, then how not stateful?

      That has nothing to do with statelessness as it describes what the client is
      doing. The request to the server definitely contains all information and
      doesn't rely on a shared state. So no, this is not stateful. Not even if
      there are 100s of requests in between. The server and any intermediary
      couldn't care less.

      As long as that document is evaluated at run-time and not at design- or
      compile-time everything is fine. Otherwise the result would be a client that
      is tightly coupled to the server.


      > > But isn't that exactly what I am proposing? We have one single
      > > initial URL, the client GETs the service document representation
      > > there and selects among the hyper media elements (the links) that
      > > are present in the received representation.
      >
      > Can everything in your API be done with one additional HTTP request
      > after the home document? If yes, then sorry, I was assuming wrong. If
      > no, does it not fail this test?
      >
      > The representation tells the client how to compose all transitions to
      > the next application state.

      Yeah. The emphasis is on "next application state". That doesn't require that
      the next state is the final state. So there can be as many steps in between
      as there are required... and every response to those intermediary requests
      can link back to the home document - just in case the client hasn't seen it
      yet. That's exactly the same as for normal websites.


      --
      Markus Lanthaler
      @markuslanthaler
    • Mike Schinkel
      Once again you have given me much to ponder. Thanks for the effort; I will be trying to internalize this. -Mike
      Message 46 of 46 , May 4 12:03 PM
      • 0 Attachment
        Once again you have given me much to ponder. Thanks for the effort; I will be trying to internalize this.

        -Mike

        On May 4, 2013, at 1:49 PM, "Markus Lanthaler" <markus.lanthaler@...> wrote:

        > On Saturday, May 04, 2013 7:03 PM, Mike Schinkel wrote:
        >> Hmm. Okay, the more I think I understand about REST the more I think
        >> I don't understand and/or am unsure who actually really understands
        >> REST besides Roy.
        >>
        >> As I've read Roy I've come away understanding that messages must be
        >> self-contained
        >
        > No, you are confusing self-contained with self-descriptive.
        >
        >
        >> and the only thing the client should know is how the
        >> links in the returned representation are defined to behave as defined
        >> by the representation's content yype. Having links in one document and
        >> data in a second document where you have to have the contents of both
        >> documents seems to me to violate that need for self-containment.
        >
        > ... if there would be a self-containment constraint that would be true --
        > but there isn't.
        >
        >
        >> I do have one question; if there is a home document that is cacheable
        >> for some period "X" and at the time immediately after an API client
        >> retrieves the home document the servers are moved and the client later
        >> perform an operation that requires URLs from the home document but
        >> before "X" time has passed, it can cause failure. If the message is
        >> self-contained that time window is greatly reduced. This is one of the
        >> reasons I can postulate there is a need for self-contained messages.
        >
        > That doesn't matter at all. Program defensively, detect the error, and
        > recover.
        >
        > I could just as well argue that separating them allows you to request them
        > in parallel which would probably be faster so the time window you are
        > talking about would be reduced even further.
        >
        >
        >
        > --
        > Markus Lanthaler
        > @markuslanthaler
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.