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

xml.com REST article

Expand Messages
  • Benjamin L Yu
    I m curious if anyone has any comments on this xml.com article: http://www.xml.com/pub/a/2004/08/11/rest.html After reading the thesis and this entire mailing
    Message 1 of 3 , Aug 13, 2004
      I'm curious if anyone has any comments on this xml.com article:
      http://www.xml.com/pub/a/2004/08/11/rest.html

      After reading the thesis and this entire mailing list archive, this
      article doesn't sit well with me for some reason. I can't pin point it
      right now, as I'll need some more time to reflect, but there are some
      areas that don't feel "right" to what I've come to learn as REST.
    • Roy T. Fielding
      ... It seems to be one person s suggestions on how to implement a REST-based service. Too bad it wasn t written that way. It would be more accurate to say
      Message 2 of 3 , Aug 14, 2004
        On Friday, August 13, 2004, at 06:31 PM, Benjamin L Yu wrote:

        > I'm curious if anyone has any comments on this xml.com article:
        > http://www.xml.com/pub/a/2004/08/11/rest.html
        >
        > After reading the thesis and this entire mailing list archive, this
        > article doesn't sit well with me for some reason. I can't pin point it
        > right now, as I'll need some more time to reflect, but there are some
        > areas that don't feel "right" to what I've come to learn as REST.

        It seems to be one person's suggestions on how to implement
        a REST-based service. Too bad it wasn't written that way.

        It would be more accurate to say that he is interleaving REST
        with SOA and some vague notion of W3C webarch, without
        understanding that REST pre-dated the other two by over three
        years and that both SOA and webarch cover topics beyond the
        hypertext realm of REST. He marks suggestions as [AR] to
        mean "arguably REST", which should really be read as
        "not part of REST but not specifically forbidden by REST".

        BTW, just about everything he wrote about methods and use
        of XML is wrong, and the stuff about query is just bad design
        from SOA (nothing at all to do with REST).

        Cheers,

        Roy T. Fielding <http://roy.gbiv.com/>
        Chief Scientist, Day Software <http://www.day.com/>
      • S. Mike Dierken
        I hadn t seen it till you pointed it out. The first part is a generic summary of the past two years. I think fundamentally the author mistakes architecture and
        Message 3 of 3 , Aug 14, 2004
          I hadn't seen it till you pointed it out.
          The first part is a generic summary of the past two years. I think
          fundamentally the author mistakes architecture and architectural style for a
          software application framework - he seems to be looking for . The phrase
          'despite the lack of vendor support' is laughable (an architecture doesn't
          require vendor support, software which easily supports this style is freely
          available as well as from vendors, wouldn't 'winning the hearts of
          developers' indicate that 'vendor' is not a required component of the
          architecture, etc).

          I do think an effort to highlight best practices is good, but some of the
          statements are way off base:
          "This limits the interface to HTTP with the four well-defined verbs: GET,
          POST, PUT, and DELETE". - Nothing limits REST to be HTTP, nor does HTTP have
          only four verbs.

          "A REST service is a resource" - This seems odd. I would have thought a REST
          service would have multiple resources (or maybe the author indicates that
          the service itself could be a single identifable resource that can be
          interacted with?)

          "URI opacity only applies to the path of a URI. The query string and
          fragment have special meaning that can be understood by users. " - This is
          incorrect. A URI (and the benefits of opacity) apply to the whole URI, not
          just the path segments. Any part of a URI can be used to coordinate between
          clients and server (such as HTML forms), but there is an integration cost
          and an increase in coupling if that is done. Avoiding situations that
          require /every possible/ client to clearly understand portions of a URI
          would be a best practice.

          "A service provider should ignore any query parameters it does not
          understand during processing. If it needs to consume other services, it
          should pass all ignored parameters along. This practice allows new
          functionality to be added without breaking existing services." - this is
          questionable and I'd like to see real analysis of this (especially in the
          scenario where an origin server is internally acting as a
          gateway/intermediary).

          "[TIP] XML Schema provides a good framework for defining simple types, which
          can be used for validating query parameters." - If this is intended to put
          data typing in the URI, then it seems the opposite of a 'loose typing good,
          strong typing bad' approach to integration. If this is for internal
          operations only, then I think most any implementation language that uses
          strong typing is a framework for validating incoming data of any kind.

          "Proxy-driven negotiation. A client initiates a request to a server through
          a proxy. The proxy passes the request to the server and obtains a list of
          representations. The proxy selects one representation according to
          preferences set by the client and returns the representation back to the
          client." - this doesn't sound very stateless & having a client set a
          preference is equivalent to having a client send a preference via the Accept
          header.

          "When delivering a representation to its client, a server MUST check the
          following HTTP headers: Accept, Accept-Charset, Accept-Encoding,
          Accept-Language, and User-Agent to ensure the representation it sends
          satisfies the user agent's capability. " - no, a server doesn't. It 'should'
          check them, but low budget servers (embedded http servers in devices, etc)
          should just do whatever they want and have the client deal with it. That is
          a key aspect of the architecture that enables loosely coupled and evolvable
          systems.

          "A server may determine the type of representation to send from the profile
          information of the client." - what is a 'profile of the client'? Is a client
          the same as user-agent? or is it a specific instance of a client
          application? And if so, wouldn't that make the processing of a request
          stateful?

          "A client can specify the representation using the following query string:
          mimeType={mime-type}" - this is questionable, but useful in practice.
          However, using the same name as the HTTP request header (content-type) would
          greatly ease the education and meaning of the query term. In addition, the
          client should use the Accept header instead & the server should respond with
          a Location response header with the alternate URI of the requested
          content-type - this allows the client to talk to any server without knowing
          whether it does or does not support this query term, and it allows server to
          choose where in the URI to embed content-type information (it could be in a
          file extension like .txt or .pdf or .doc, or it could be a path segment if
          things are stored in file directories, etc. etc.)

          "A REST server should support this query." - HTTP based REST servers already
          support this query via a standardized request mechanism - the Accept header.
          In addition the Accept header has more well thought out capabilities and
          syntax than this under-specified query term.

          "A resource may have different views, even if there is only one
          representation available. For example, a resource has an XML representation
          but different clients may only see different portion of the same XML.
          Another common example is that a client might want to obtain metadata of the
          current representation. To obtain a different view, a client can set a
          "view" parameter in the URI query string" - If a query term is used, then
          this is a different URI which this means that there are different resources.
          There is not 'one resource with different views'. The concept exists, but it
          isn't part of the vocabulary of the REST definition. In addition, the
          assertion that "a client can set a 'view' parameter" is highly misleading
          and likely will cause developers to try it and fail and blame REST rather
          than the author.

          "A service represents a specialized business function" - this sort of avoids
          the 'resource modeling' viewpoint which is fundamental to REST.

          "A request to an obligated service should be described by some kind of XML
          instance, which should be constrained by a schema" - what if the service
          support storage of MP3 files? Or MS-Word documents? How are those described
          via XML?

          "An obligated service should be made idempotent so that if a client is
          unsure about the state of its request, it can send it again." - if a
          resource supports POST, then it isn't idempotent. If idempotency is desired,
          then the resource model should be built to support PUT. (Unless you use some
          theoretical protocol not based on HTTP that makes idempotency configurable
          per request or something)

          "Return a receipt immediately upon receiving a request. " - it probably
          should use the appropriate HTTP response status code as well.

          "Transaction Lifecycle " - this looks interesting and hope this work helps
          flesh out details of the underspecified 'Accepted' response status code.


          ----- Original Message -----
          From: "Benjamin L Yu" <benjaminlyu@...>
          To: <rest-discuss@yahoogroups.com>
          Sent: Friday, August 13, 2004 6:31 PM
          Subject: [rest-discuss] xml.com REST article


          > I'm curious if anyone has any comments on this xml.com article:
          > http://www.xml.com/pub/a/2004/08/11/rest.html
          >
          > After reading the thesis and this entire mailing list archive, this
          > article doesn't sit well with me for some reason. I can't pin point it
          > right now, as I'll need some more time to reflect, but there are some
          > areas that don't feel "right" to what I've come to learn as REST.
          >
          >
          >
          >
          >
          >
          >
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.