RE: ATOM representation of search result facets

Hi Eric,

I agree a custom attribute is a better way.  And yes, Atom is made to be extensible, so that fits nicely.

All that said, there is nothing about application/atom+xml which implies this extension.  To be self-descriptive, to pick up on the theme from another thread, the client has to request these semantics somehow, and the server has to communicate the fact that they are being provided.  The RESTful way to do this is not through sniffing, but media types.

If the client does request application/atom+xml and receives the extension, no harm is done because of atom's must ignore model.

If the client does request the extension via a custom media type, it expects to be able to process the response based on the Content-Type value returned.

Peter
________________________________________
From: Eric J. Bowman [[email protected]]
Sent: August 30, 2012 1:10 AM
To: Rushforth, Peter
Cc: Rich Cariens; [email protected]
Subject: Re: [rest-discuss] ATOM representation of search result facets

"Rushforth, Peter" wrote:
>
> As long as you don't use the application/atom+xml media type to
> describe it, you should be OK.
>

You're not wrong, but I think there's a better way to look at it -- by
staying true to the generic media type, rather than forking it to be a
custom media type for one point of data.  This can be done by extending
Atom (which doesn't change the media type, i.e. it's still application/
atom+xml), or perhaps just using an ugly hack like this:

<link rel="related" title="Canon" type="application/atom+xml"
href="/search?q=35mm&fq=Manufacturer%3DCanon...">length=134</link>

This just introduces some domain-specific vocabulary in the link text,
without tripping up any generic Atom processors.  To me this is far
preferable to excluding generic Atom processors from the communication
by introducing a new media type such processors won't recognize as
something they can handle (not without sniffing, anyway).

-Eric