Re: Content types and links

"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."

This is essentially what we do internally to support it. Default is normal atom.

There are of course trade offs. I like the x.json to at least make it
explicit what they are risking if they decide to use it.

On Thu, Sep 6, 2012 at 8:52 PM, Eric J. Bowman <[email protected]> wrote:
> 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



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