Re: Content types and links

Actually I meant to type Accept :) I was reading/typing two things at
once. Likely header came in because I was reading "headers" from curl
:)

We have sat on the fence for a while about how to handle content type
here as there is no 'good' answer. If I do as x. I break tools. If I
don't I break "rest". I have still not made a decision on how to
handle this.

The interesting bit to me was if I am in that format (and we assume
you are coming to me to read a feed)  do the others have value?

Greg

On Thu, Sep 6, 2012 at 3:44 PM, Eric J. Bowman <[email protected]> wrote:
> Greg Young wrote:
>>
>> Header: JSON
>>
>
> I assume you mean "Accept: application/json", which I'd rather you
> would type than me...
>
>>
>> Would it seem off to you that I gave you the alternates?
>>
>
> Conceptually, no, there's nothing wrong with including a list of
> alternates using rel='alternate' in any media type which implements link
> relations.  Which application/json doesn't, meaning your example doesn't
> implement REST.  Sure, you can serialize Atom as JSON or XML, but the
> results aren't self-descriptive, which violates the uniform interface
> constraint.
>
> The fix is to define a JSON serialization of Atom and register
> application/atom+json for it; in the meantime, it's important to
> understand where your system deviates from REST's idealized model.
> It's become de rigeur to serialize Atom as JSON in this fashion, but it
> doesn't meet Roy's definition of visibility, because everyone does it a
> little bit differently while visibility is a product of standardization.
>
> All those similar efforts slap application/json on it, which is truly
> opaque because that media type doesn't define linking. Meaning the only
> way to deduce "hey, this is Atom" is by sniffing the content and making
> lots of assumptions about syntax.  Standardization is required for this
> to become visible; even then, proliferation is required before REST's
> benefits would be fully realized.
>
> Using REST as an evaluation tool in this manner, presents you with two
> options:  one, re-architect the system, if you need the full benefits of
> REST from the get-go; or two, wait for the Web to catch up, participate
> in the standardization process by writing an I-D for the Atom WG.  I'd
> suggest, if you have to build your system this way, using a media type
> of application/x.atom+json until such time as standardization occurs.
>
> -Eric



-- 
Le doute n'est pas une condition agréable, mais la certitude est absurde.