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