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

Re: [rest-discuss] ATOM representation of search result facets

Expand Messages
  • Eric J. Bowman
    ... Nor does such requirement exist. ... I see nothing in the self-descriptive messaging constraint which requires markup-language versioning to be expressed
    Message 1 of 33 , Aug 31, 2012
    • 0 Attachment
      "Rushforth, Peter" wrote:
      > All that said, there is nothing about application/atom+xml which
      > implies this extension.

      Nor does such requirement exist.

      > To be self-descriptive, to pick up on the theme from another thread,
      > the client has to request these semantics somehow, and the server has
      > to communicate the fact that they are being provided. The RESTful
      > way to do this is not through sniffing, but media types.

      I see nothing in the self-descriptive messaging constraint which
      requires markup-language versioning to be expressed via media type. To
      me, REST is contained entirely within Dr. Fielding's dissertation,
      including the definitions of terms used to distinguish one
      architectural style from another. There are other ways of doing
      things, but if they require any redefinition of Roy's terms in order to
      be considered RESTful, the disservice isn't being done to REST(tm), but
      to REST's usefulness as an evaluation tool.

      Nobody has to implement REST, but if your idiom is that of networked
      hypertext systems, an understanding of where you are deviating from
      REST and the consequences of same, is required. We can't begin to
      discuss the real-world consequences of overloading media type to
      precisely capture the meaning of a hypertext interface, versus using
      media type to identify a codec, unless we can agree that these are two
      different approaches with different outcomes -- and thus worthy of
      separate definitions so we can have that discussion using precise terms.

      Which we can't do, if the starting point of the debate is that one of
      these approaches just isn't RESTful enough, despite meeting Roy's
      definition of self-descriptiveness, causing the discussion to degrade
      into accusations of pedantry and un-usefulness. Do what's best for your
      system, whether the result is precisely RESTful or not isn't a value
      judgment, it's an evaluation tool. Instead of attempting to redefine
      Fielding in an effort to attach the REST(tm) label, embrace REST the
      tool by using Fielding's definitions to explain what tradeoffs you
      made, and why you made them for the system in question.

      REST is an idealized model, if fewer people would set it as a goal with
      the naive expectation that real-world systems are even likely to fully
      comply, we'd see less effort made to pass anything and everything off as

      > If the client does request application/atom+xml and receives the
      > extension, no harm is done because of atom's must ignore model.

      Graceful degradation doesn't harm any clients, right.

      > If the client does request the extension via a custom media type, it
      > expects to be able to process the response based on the Content-Type
      > value returned.

      Now you're talking about no degradation, as if the only clients that
      care about your payload are privy to your application. Having an
      infinite number of finely-grained media types defeats the whole point
      of self-descriptive messaging by actually reducing visibility, again
      sticking with Roy's definition of terms. One key to the successful
      scaling of the Web has been the small number of ubiquitous, coarse-
      grained media types. This is a feature, not a bug; yes, there are
      disadvantages, but it's a tradeoff we're willing to make in REST:

      "The trade-off, though, is that a uniform interface degrades
      efficiency, since information is transferred in a standardized form
      rather than one which is specific to an application's needs."

      Whether you are willing to make the same tradeoff in your system is for
      you to decide, but it's incorrect to claim that using more application-
      specific media types makes the result more RESTful (or self-descriptive,
      or visible). What this tradeoff allows, is for your system to scale by
      targeting the deployed architecture of intermediaries which do all
      sorts of wonderful things with your content based on the ubiquitous
      markup you're using, and simply don't care about understanding any of
      your domain-specific vocabulary.

      The reason fine-grained media types exclude intermediary participation,
      is because you've tightly coupled client to server. As designed (by
      which I mean coarse-grained), the concept of media types promotes loose
      coupling. This has led to a proliferation of intermediaries performing
      every task under the sun nowadays, for billions of *different* systems
      using essentially *the same* small number of ubiquitous media types.
      Restricting intermediaries to only those which fully understand every
      last bit of domain-specific vocabulary your system uses, completely
      misses the point of REST as an architectural style, by lacking the
      key ingredient for meeting REST's scalability goal (ubiquitous media

      Profile attributes, otoh, offer a reasonable compromise by more fully
      describing the document semantics (not to be confused with self-
      descriptive messaging, currently the most prevalent misconception of
      REST out there imo) while still identifying the coarse-grained codec
      wire-speed clients (by which I mean intermediaries) need to determine
      if there's *anything* they can do with the payload, which likely has
      nothing to do with the specifics of your application.

    • Erik Wilde
      ... well-designed media types do not allow you to do this. you can extend such a media type, but if your extension is a mustUnderstand , then you re messing
      Message 33 of 33 , Sep 14, 2012
      • 0 Attachment
        > I don't know. If you override the meaning of an attribute in atom,
        > can it still be safely processed as atom? I know, you're going to
        > say, depends on which attribute. I'm not as strict in what I do
        > as in what I tell others to do ;-). Just trying to think it through!

        well-designed media types do not allow you to do this. you can extend
        such a media type, but if your extension is a "mustUnderstand", then
        you're messing with the foundation. then again, there are media types
        that have "mustUnderstand" semantics built into the foundation, so that
        an extension can signal what you can and cannot safely assume when
        you're not supporting the extension. atom has no such mechanism, and
        defining an extension that alter the semantics of atom markup would be
        bad design.



        erik wilde | mailto:dret@... - tel:+1-510-2061079 |
        | UC Berkeley - School of Information (ISchool) |
        | http://dret.net/netdret http://twitter.com/dret |
      Your message has been successfully submitted and would be delivered to recipients shortly.