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

Re: [rest-discuss] Representations

Expand Messages
  • Roy T. Fielding
    ... Actually, there should be all three if you want a negotiated resource. It is important to understand that these are three *different* resources (resource
    Message 1 of 36 , Oct 26, 2009
      On Oct 26, 2009, at 10:19 AM, Will Hartung wrote:

      > Thinking about this a little more, I have a question I'd like
      > clarified.
      >
      > We talked about unique naming and how there shouldn't be /resource.xml
      > and /resource.json, but rather /resource and two representations based
      > on the Accept header.

      Actually, there should be all three if you want a negotiated resource.
      It is important to understand that these are three *different*
      resources (resource != file). Each identifier corresponds to a
      unique semantic and mapping over time.

      > But in hindsight, what's the difference between
      >
      > GET /resource.xml
      > GET /resource.json
      >
      > and
      >
      > GET /resource
      > Accept: application/xml
      >
      > GET /resource
      > Accept: application/json
      >
      > Semantically, the queries can be identical. Logically, one would
      > ASSUME they're identical.

      The former are requests on two different resources. The latter
      are two varying requests on one resource. The only difference,
      in my opinion, is that the single varying resource makes for a
      better bookmark because it is less susceptible to both
      differences in user agent capabilities (different accept lists)
      and changes in supported media types over time. It is not,
      however, a replacement for the media-specific resources and
      their corresponding URIs.

      A better protocol would tell the client the available variants
      and how to get them, preferably in a way that doesn't impact
      latency (trailers). Yes, that was in HTTP/1.1's original design.

      The media-specific resources are also useful for the apps
      that don't want to negotiate, especially those performing
      remote authoring or versioning.

      ....Roy
    • William Martinez Pomares
      Hello Will. The thread is looong and taking into account too many HTTP specifics, which if you read my comments I tend to be away from. Also, it seems Roy
      Message 36 of 36 , Oct 27, 2009
        Hello Will.
        The thread is looong and taking into account too many HTTP specifics, which if you read my comments I tend to be away from.
        Also, it seems Roy already answered what I was going to write.

        Anyway, I will write it :D

        --- In rest-discuss@yahoogroups.com, Will Hartung <willh@...> wrote:
        >
        > Thinking about this a little more, I have a question I'd like clarified.
        >
        > We talked about unique naming and how there shouldn't be /resource.xml
        > and /resource.json, but rather /resource and two representations based
        > on the Accept header.
        >

        The naming of /resource.ext should not mean anything to the client, but taking into account the human part, it will lead the developer to think the .ext part of the URI is a type indicator.

        > But in hindsight, what's the difference between
        >
        > GET /resource.xml
        > GET /resource.json
        >
        > and
        >
        > GET /resource
        > Accept: application/xml
        >
        > GET /resource
        > Accept: application/json
        >

        Well, the difference, in the REST context, is clear: They are three different URIs, and thus under the eyes of the client they are three different resources (although not necessarily three different ones!).
        What I mean is, you have there three different "names" or ID for resources, and to the client they are three resources, period. Now, since a resource can have more than one name, then they may be the same resource. Note that I'm not talking about files here, but resources. In fact, there may be only one resource with two representations (a service that generates XML of JSON on request), and each URI approaches the same resource in a different way. But all is hidden in the implementation, and client does not know that.

        It may not mean a major difference from your insider view, but from the client view it is more complicated. See?

        BTW, that approach of service allows for expansion and evolution. YOu can add new representation whenever you like. But, in that case, the generic /resource plus ACCEPT is the best choice.

        > Semantically, the queries can be identical. Logically, one would
        > ASSUME they're identical.
        >
        Queries is a word that itches here, but that is already mentioned somewhere else.

        To the client, it may be requesting any of three URIs, no queries, and each URI will return something different. One will return only xml representation, the other only JSON representation (and may not be related to the URI composition!) and the last one allows negotiation of the type. Simple.

        > From a caching point of view, they are separate requests. A cache that
        > has the XML representation won't be able to answer a JSON query, so
        > both have a similar caching impact in terms of ensuring that the cache
        > is properly synced with both representations.
        >

        To a cache system, it depends. For instance, in DB world: If you cache systems identifies cached results by exact query, then any two SQL statement that differs in one space, or in the order of the Where clauses, will create a copy of results to cache.

        Now, if the cache is an intelligent one, it will identify the result by its properties, rather by the SQL statement that generated them. So, later, another SQL statement that may require a subset of the result that is already in cache, will make the cache activate and avoid another DB call! Even more, the cache can see if part of the query is already answered in cache, and then not to perform the complete query since it already has some data.

        In this example, fear not of the URIs, but of your cache intelligence.
        Taking into account that you can have 100 URIs all pointing to the same resource, the cache that works against a canonical resource name will have no problem, but if it works with the URI, then it will load 100 copies of the same thing.

        Cheers!

        William Martinez Pomares
      Your message has been successfully submitted and would be delivered to recipients shortly.