Re: Content types and links

Greg Young wrote:
> 
> 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.
> 

Decide whatever you want, provided you understand the ramifications.
Tools will eventually grok the +json media type suffix.  REST is about
long-term design, there's nothing wrong with having to wait a few years
for standardization to catch up. When it does you'll hopefully not have
painted yourself into a legacy-support corner, by failing to anticipate
change or planning how to accommodate it when it comes, in the design
phase.

>
> 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?
> 

I don't think there's much value to having multiple serializations,
seems more like something folks do in order to check boxes for feature
support, mostly.  If you're running an origin server and offering a
JSON serialization for Atom content, anyone building a client to consume
that JSON will have their client break if/when you change syntax to
support a standardized solution, due to tight coupling -- which isn't an
issue when standard media types are adhered to.

Whereas, if you only offer Atom, client developers can always add a
layer (using, say, XSLT) which transforms your Atom into their desired
JSON.  If/when a standardized solution to that problem evolves, the
client developer can decide whether or not to support it -- nothing
breaks, so you're not in a position where you need to support legacy
code by adding conneg on application/x.atom+json vs. application/atom+
json, which increases the complexity of your system.

I don't know your requirements, but I'd wait until the desired feature
(Atom serialized as JSON) actually exists before implementing it, rather
than trying to hit a moving target.  Once application/atom+json is
nailed down, it's easy enough to add in support to please client
developers, without the extra complexity of supporting legacy code.
Client developers can then remove their transformation layer, and change
their Accept: header to request atom+json instead of atom+xml.

In the meantime, there are benefits to be had from serving Atom as Atom,
which are a long ways off for Atom serialized as JSON.  Intermediaries
aren't just caches, those with knowledge of Atom can prefetch DNS
lookups, or atom:entry documents, or images etc. while third-party
systems (i.e. Google) know how to handle (index, subscribe to) your
data.  As a REST true believer, I don't see the benefit of trading away
this global, ubiquitous support of any system for the sake of easier
development of tightly-coupled clients.  Or, for byte shaving, which is
a moot point when compression and caching are considered.

http://tech.groups.yahoo.com/group/rest-discuss/message/8873

Put another way, REST enables serendipitous re-use by all sorts of apps
which have no knowledge of your system specifics.  Why give that up to
support the comparatively tiny number of applications developed
specifically for your system?  OK, sure, you can use conneg, but if the
tiny number of purpose-built clients accounts for most of your users
you're just shooting yourself in the foot -- their usage won't be
accelerated via serendipitous re-use, and will degrade cache efficiency
for any ubiquitous-media-type representations you're serving.

I think when Roy says "engineer for serendipity" it applies to runtime,
but is commonly misinterpreted to apply to design-time, which has led
lots of folks to implement multiple serializations.  I don't think Roy
means "make it easier for third parties to write clients" so much as
"support those clients already existing as part of the deployed
infrastructure" because that's what allows a system to truly scale.  By
doing so, your system will automatically support any new clients added
to the deployed infrastructure, which are based on the same standards
you've adhered to.  You don't need to know about them, and they don't
need to know about you, which sounds pretty serendipitous to me.

By clients, I mean both client connectors on intermediaries, and such
things as googlebot.  Target those by using ubiquitous media types which
properly describe the linking/embedding semantics of your data.

-Eric