On Thursday, December 07, 2006, at 06:24PM, "Steve Jones" <[EMAIL PROTECTED]> wrote: >On 07/12/06, Jan Algermissen <[EMAIL PROTECTED]> wrote:
>So what you are saying therefore is that for REST you need to publish >a document (like the one you referenced) for every resource that you >are trying to expose? Not quite. Representations (what you receive upon GET or what you POST or PUT) have a MIME type. The MIME type defines the meaning of the representations and obviously the knowledge about the MIME type needs to be shared between client and server. Without shared semantics, you cannot communicate. The document you reference details how some >content can be formed but what happens when I need to actually process >the content within the atom wrapping? That has a MIME type too. In somewhat sloppy words: all data in REST is typed. With regard to HTTP these types are called MIME types. Surely myself and the originator >must have some shared understanding Yes, exactly. or perhaps you expect some >intermediary to do the conversion - in which case it must have shared >understanding of what I want and what the sender provides? Yes, exactly. > >So how is that communicated? NIcely :-) REST is all about standardization. REST moves all the specifics into the representation types (it must do so, since the interface is uniform). The need for integrating semantics does not go away, but integration is much less complex at the data level than at the interface level (e.g. you need not pay attention to call sequences of interface methods). Besides: Having a non-uniform interface (ala WS-*) does not mean you have no integration issue at the data level. Bottom line: with a uniform interface, there is simply one thing less to worry about. >> >> > >> >> >> >> Nobody said you should use a media type with just one link semantic >> >> (<a href..>) for machine to machine interaction! >> > >> >What other standard semantics are there? I'm still not understanding >> >how consumers have the meaning communicated to them in advance. >> >> See browser-finds-stylesheet use case above. >> Read the atom pub protocol specs with a good eye on app:collections and how >> client software picks them. The read the atompub-features extension >> (http://tools.ietf.org/wg/atompub/draft-snell-atompub-feature-01.txt) to >> see how >> collections (processors) can be picked by capability (aka by type). > >And how do you communicate the meaning of that type to the consumer? It simply has to be shared before the communication takes place. No magic. Useful specs (mostly those that hit the 80/20 spot) are likely to prevail over complex ones, more people/companies/departments (pick your context) will reuse them, leading to further pervasive semantics. Network effects. HTH, Jan >The spec describes an envelope, but not the meaning of the content >(sort of like the SOAP spec). > >> >> Cheers, >> Jan >> >> > >> >> >> >> Jan >> >> >> >> >> > >> >
