Re: [rest-discuss] Combining HTML and XML?
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
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?
- Roy T. Fielding wrote:
> On Jan 3, 2011, at 6:22 PM, Eric J. Bowman wrote:Indeed, you often need the conflicting implementations in order to
>> 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.
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?