Re: ATOM representation of search result facets

"Rushforth, Peter" wrote:
> 
> All that said, there is nothing about application/atom+xml which
> implies this extension.
>

Nor does such requirement exist.

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

I see nothing in the self-descriptive messaging constraint which
requires markup-language versioning to be expressed via media type.  To
me, REST is contained entirely within Dr. Fielding's dissertation,
including the definitions of terms used to distinguish one
architectural style from another.  There are other ways of doing
things, but if they require any redefinition of Roy's terms in order to
be considered RESTful, the disservice isn't being done to REST(tm), but
to REST's usefulness as an evaluation tool.

Nobody has to implement REST, but if your idiom is that of networked
hypertext systems, an understanding of where you are deviating from
REST and the consequences of same, is required.  We can't begin to
discuss the real-world consequences of overloading media type to
precisely capture the meaning of a hypertext interface, versus using
media type to identify a codec, unless we can agree that these are two
different approaches with different outcomes -- and thus worthy of
separate definitions so we can have that discussion using precise terms.

Which we can't do, if the starting point of the debate is that one of
these approaches just isn't RESTful enough, despite meeting Roy's
definition of self-descriptiveness, causing the discussion to degrade
into accusations of pedantry and un-usefulness.  Do what's best for your
system, whether the result is precisely RESTful or not isn't a value
judgment, it's an evaluation tool.  Instead of attempting to redefine
Fielding in an effort to attach the REST(tm) label, embrace REST the
tool by using Fielding's definitions to explain what tradeoffs you
made, and why you made them for the system in question.

REST is an idealized model, if fewer people would set it as a goal with
the naive expectation that real-world systems are even likely to fully
comply, we'd see less effort made to pass anything and everything off as
RESTful.

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

Graceful degradation doesn't harm any clients, right.

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

Now you're talking about no degradation, as if the only clients that
care about your payload are privy to your application.  Having an
infinite number of finely-grained media types defeats the whole point
of self-descriptive messaging by actually reducing visibility, again
sticking with Roy's definition of terms.  One key to the successful
scaling of the Web has been the small number of ubiquitous, coarse-
grained media types.  This is a feature, not a bug; yes, there are
disadvantages, but it's a tradeoff we're willing to make in REST:

"The trade-off, though, is that a uniform interface degrades
efficiency, since information is transferred in a standardized form
rather than one which is specific to an application's needs."

Whether you are willing to make the same tradeoff in your system is for
you to decide, but it's incorrect to claim that using more application-
specific media types makes the result more RESTful (or self-descriptive,
or visible).  What this tradeoff allows, is for your system to scale by
targeting the deployed architecture of intermediaries which do all
sorts of wonderful things with your content based on the ubiquitous
markup you're using, and simply don't care about understanding any of
your domain-specific vocabulary.

The reason fine-grained media types exclude intermediary participation,
is because you've tightly coupled client to server.  As designed (by
which I mean coarse-grained), the concept of media types promotes loose
coupling.  This has led to a proliferation of intermediaries performing
every task under the sun nowadays, for billions of *different* systems
using essentially *the same* small number of ubiquitous media types.
Restricting intermediaries to only those which fully understand every
last bit of domain-specific vocabulary your system uses, completely
misses the point of REST as an architectural style, by lacking the
key ingredient for meeting REST's scalability goal (ubiquitous media
types).

Profile attributes, otoh, offer a reasonable compromise by more fully
describing the document semantics (not to be confused with self-
descriptive messaging, currently the most prevalent misconception of
REST out there imo) while still identifying the coarse-grained codec
wire-speed clients (by which I mean intermediaries) need to determine
if there's *anything* they can do with the payload, which likely has
nothing to do with the specifics of your application.

-Eric