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

Re: [rest-discuss] Combining HTML and XML?

Expand Messages
  • Juergen Brendel
    Hello! ... Yes, I did notice that: You try to design HATEOAS into your API and before you know it you start to invent your own @rel tags, since that seems to
    Message 1 of 57 , Jan 3, 2011
      Hello!

      On Wed, 2010-12-29 at 19:26 -0700, Eric J. Bowman wrote:
      > I think most folks are still making this too hard on themselves, and
      > others. I'm disappointed by how often what appears to be hypertext-
      > driven, really depends on magical out-of-band processing rules being
      > switched on when encountering nonstandardized strings in Content-Type
      > or @rel, which isn't actually what hypertext as the engine of state
      > means in the context of REST's uniform (standardized) interface.

      Yes, I did notice that: You try to design HATEOAS into your API and
      before you know it you start to invent your own @rel tags, since that
      seems to be so easy and expressive. I understand your concern about
      this. I have to admit that I have done the custom-rel thing myself,
      since I found the existing lists of available definitions
      unsatisfactory.

      Clearly, I'm doing something wrong?

      I guess my first question would be: Where can I find the definitive list
      of defined 'rel' values? I found different ones, which don't all seem to
      agree on what's really defined. Or is the 'rel' value something defined
      in the media type definition?

      Juergen


      --
      Juergen Brendel
      MuleSoft
    • Nathan
      ... Indeed, you often need the conflicting implementations in order to standardize, however I think the key conceptual difference Eric has been trying to get
      Message 57 of 57 , Jan 4, 2011
        Roy T. Fielding wrote:
        > On Jan 3, 2011, at 6:22 PM, Eric J. Bowman wrote:
        >> I still fail to see how both diametrically-opposed approaches can
        >> possibly be based on the same thesis. Roy's examples have never been
        >> based on the creation of custom data/media types. If REST were worded
        >> in a completely different way than it is, and Roy's examples always
        >> (instead of never) started with the creation of custom types, then I'd
        >> be wrong. But, REST and Roy are both quite clear that the style is NOT
        >> about creating custom media/data types, but is in fact the exact
        >> opposite of that approach.
        >
        > Do keep in mind that, in order to have an *evolving* set of standard
        > media types (and likewise standard link relations), there will have
        > to be new media types being created and old media types fading away
        > over time.
        >
        > One person's experiment may well become another person's standard,
        > in the long run, and REST is very much about the long run. So we
        > should consider new media types in terms of their long-term intent
        > rather than their immediate status.

        Indeed, you often need the conflicting implementations in order to
        standardize, however I think the key conceptual difference Eric has been
        trying to get across is summed up in your statement above, that we
        "should consider new media types in terms of their long-term intent",
        the distinction being that a media type being created with the long term
        in mind, with the principals like separation of concerns and
        web/internet-scale usage in mind, is RESTful (in the context of the
        web); whilst just dumping out an object from an application in XML,
        registering a +xml vnd type and creating a custom client, is not.

        Is that a fair comment / distinction to make?

        Best,

        Nathan
      Your message has been successfully submitted and would be delivered to recipients shortly.