On 10/12/06, Jan Algermissen <[EMAIL PROTECTED]> wrote: > > > > > > > > On Dec 10, 2006, at 8:52 PM, Steve Jones wrote: > > >> > >> An example: > >> > >> If one asks: how do I go about order processing with HTTP, the > >> answer > >> would > >> usually need to include that the media type to be used for > >> representing orders > >> would include the necessary link and form semantics to enable order > >> processing > >> and that it would include a means to represent orders. > >> > >> If we assume Atom and APP to be pervasive, the processing means are > >> already in place[1] > >> and the answer to the question would more or less be: "Atom is used > >> as the doc envelope, > >> APP handles editing, submitting, service discovery and what needs to > >> be done is to pick > >> a representation format for the orders (make up your own or pick > >> from > >> UBL, EDIFACT, > >> ebXML and friends). > > > > Now this is interesting, so what you are arguing is that Atom is in > > effect the document envelope (ala SOAP) and you'd then use UBL or > > ebXML as the representation method for orders. > > Yepp, exactly. And (that is my personall approach) whatever you need > to have the orders participate in processes you stuff into the Atom > entries > (via an Atom extension). That is, if you have a bunch of states of your > orders, put them in the atom entry and not (only) into the order (the > Atom content). > > That way - IMHO - you can bundle up process semantics as Atom > extensions and > come up with software that implement these process semantics bundles > (e.g. > "purchase" or "auditing" or "bidding" or "negotiating") > > > > > Oddly I quite like that as a solution as it standardises quite a > > bit... but is this really what REST is advocating? > > Well, REST is advocating that there is only a single interface but as > it happens, > this is less of an obstacle as it seems. Instead of calling methods > we are manipulating > resource state (Interesting quote from Fowler on this: [1]) > > > This is the first > > time I've seen it. Now if this is the case then to me that is > > formalism over kill (I struggle with ebXML and UBL from a > > comprehension perspective), but its better than nothing. > > Yepp, something more 80/20 would be *very* nice to have but noone > stops you or me > from initiating that. Document transformations (e.g. my80/20OrderDTD > to UBL) are > not the majhor obstacle later on. > > Glad I could drive home at least one point :-)
Now you have to explain to me why using ATOM as an envelope is actually different to using SOAP as an envelope, given that the meaning of the transaction and the content is stored within the envelope. Given that UBL defines not just resources but actual transitions the you would be submitting transition requests in an ATOM envelope, not making a PUT or GET request on a resource. A real world example where someone has acheived this would also make me think that it isn't just a theoretical example.
