On 07/12/06, Jan Algermissen <[EMAIL PROTECTED]> wrote: > > > > > > > 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.
What is the MIME type of an invoice? A customer? An Order? A yield based forecast? > > 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. But MIME types define a content _form_ not a content _meaning_ unless I've managed to miss MIME types as describers of meaning somewhere (MIME tells you its a video, it doesn't tell you what video) > > 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. So how come you can't actually explain this "simple" thing in a way that I can understand? Not paying attention to call sequences is an odd assertion (you can't GET something before its been PUT for starters). How do I publish to my consumers how they will get an invoice/customer/forecast/flying monkey/etc from my servers? How do I communicate how to place an order/add a customer/add events to the forecast/invade Oz/etc to my consumers? > > >> > >> > > >> >> > >> >> 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. HOW IS THIS DONE? What is the _standard_ way of communicating these things to consumers? > > HTH, > > Jan > > >The spec describes an envelope, but not the meaning of the content > >(sort of like the SOAP spec). > > > >> > >> Cheers, > >> Jan > >> > >> > > >> >> > >> >> Jan > >> >> > >> >> > >> > > >> > > >
