Re: Content types and links

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