Re: ATOM representation of search result facets

Just wanted to say thanks very much to everyone that responded. This has
been educational for me - better than any conference or training I've
attended so far.

I'm not sure yet how I'll proceed, but I have some time and a lot of food
for thought.

Thanks again,
Rich

On Sat, Sep 1, 2012 at 2:52 AM, Eric J. Bowman <[email protected]>wrote:

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