--- Steve Jones <[EMAIL PROTECTED]> wrote:
> > All objects have THE SAME interface (the same set of methods) > there > > are no > > others. Nothing that needs to be published. > > And the object format doesn't need to be published either? The > request formats? Absolutely they do (though I'd call them media types to be consistent). > And how do you specify how the object's state will be manipulated? > How do you tell the consumer the acceptable formats for the > manipulation of that state? That's likely the missing link in REST, IMHO, and this entire discussion. Frankly there's a dearth of microformats and domain-specific hypermedia types. Which is why REST adoption has been so slow in the enterprise, and why it's so hard to wrap one's head around. There simply are a dearth of examples, at global scale, over time, to demonstrate the value in the architecture. The only example is the HTML web. The RSS or Atom web is another growing example. But we need a business-focused example. I don't think it's because they're impossible to create, it's more likely that it most industry groups that work on shared specs aren't thinking of hypermedia as a viable architecture. They're stuck on message exchange. > I'm equally stunned that people struggle with the difference between > invocation and application. POST/PUT are not sufficient to say how > REST will implement a complex resource like inventory to enable > different types of inventory management to be implemented. HTTP would never do that. A set of formalized, standardized, and registered inventory management media types would explain how that works, how HTTP's methods map to some kind of intent in such a system. Hopefully such media types would re-use others (like XForms or XLink) to work well with others. Some mix of the two would explain the HTTP method to use on a link in a document, would formally point to the media type, and if necessary, the schema for that media type. (WebForms 2.0 and XForms are examples of how would could do this in a domain-independent way.) And we would need to extend browsers and/or introduce new kinds of user agents to understand these new media types. HTTP/REST interfaces & media types today that aren't for browser consumption are somewhat informal. They are a great start, and can get you quite far, which has been the focus of my position in this discussion so far -- HTML+microformats are very powerful. But there haven't been a great deal of IANA-registered vertical XML vocabularies and a wide variety of publicly available implementations. Whereas, those for browser consumption, media types are quite formally specified, registered, and have multiple implementations. I think a lot of the frustration in these debates is this chicken & egg problem. REST/HTTP is very early adopter territory today, for systems integration. It hasn't "crossed the chasm", so to speak. There's a lot of informalism in HTTP REST today like in any new and developing area, just like SOAP circa late 2000 (back when we thought actors were important and SOAP encoding was the primary justification for the spec, since XML Schema didn't yet exist ;-) > If REST has a uniform application interface that consists ONLY of > that > defined in HTTP then this should be sufficient. If however you > require additional elements such as MIME types or XML Schemas then it > isn't and there are additional elements that are required to fully > specify the application/service level interfaces. And that's absolutely true. There are many other specifications composed in HTTP via reference. The value in HTTP is in the consistent interface it exposes, but it stands on the shoulders of others, and requires new media types to apply in new areas. Cheers Stu ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com
