RE: ATOM representation of search result facets

Erik Mogensen <[email protected]>
Newsgroups gmane.comp.web.services.rest
Message-ID <CADbGZjanaWe2MSzZdgWNOA7GbxfavvvAa3JmJwjwE52JjhKOAA@mail.gmail.com>
Den 30. aug. 2012 23:59 skrev "Rushforth, Peter" <
[email protected]> følgende:

lol. I'm Norwegian.

>
>
>
> Hi Erik,
>
>
> >It's not interesting to ask if it is more or less RESTful to do things
using OpenSearch. I feel
> >it's a way of decoupling the server and the client; the server may or
may not include
> ><Query> elements, and the clients may or may not understand them if they
do, and don't >break if they're not there. It caters for evolvability in
both, and that's a big benefit.
>
> Rich did ask about REST. You've given him suggestions about extending
atom to include Opensearch markup, without mentioning how this impacts the
RESTful-ness of the interactions.

Yeah, I expected some reactions to that statement.  I do see the (slightly)
reduced visibility (pun not intended) of the extensions not being present
in the media type, but I'm not sure that this in any way makes the system
as a whole lose out on anything, or be "more" or "less" RESTful.

>
> If one extends or overloads atom content with Opensearch or elements in a
custom or no namespace, you are still changing the semantics of the
content. To maintain the self-describing messages constraint, you need to
do something about the media type, otherwise that content remains opaque,
or out-of-band.

But would that mean that you discount all the extensions to atom? Like
paging? atompub? None of these are mentioned in the spec for the atom media
type, but I would hardly characterize the use of them as opaque. Any
generic atom processor can work the documents and get a lot of value. Those
who know some extensions get a better experience than the rest.

Take HTML and the @profile attribute. It is an extension mechanism which
isn't visible in the HTTP headers; does that make using the profile
attribute less RESTful?

In any case, my point was to move the discussion from "is it RESTful" to
"is it useful".  OpenSearch is certainly useful, so are many of the atom
extensions out there. They often enable loose coupling in
machine-to-machine scenarios, where tight coupling is the norm.
 Den 30. aug. 2012 23:59 skrev "Rushforth, Peter" <
[email protected]> følgende:

> **
>
>
> Hi Erik,
>
> >It's not interesting to ask if it is more or less RESTful to do things
> using OpenSearch. I feel
> >it's a way of decoupling the server and the client; the server may or may
> not include
> ><Query> elements, and the clients may or may not understand them if they
> do, and don't >break if they're not there. It caters for evolvability in
> both, and that's a big benefit.
>
> Rich did ask about REST. You've given him suggestions about extending atom
> to include Opensearch markup, without mentioning how this impacts the
> RESTful-ness of the interactions.
>
> If one extends or overloads atom content with Opensearch or elements in a
> custom or no namespace, you are still changing the semantics of the
> content. To maintain the self-describing messages constraint, you need to
> do something about the media type, otherwise that content remains opaque,
> or out-of-band.
>
> Peter
>
>  
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.