On 11/12/06, Stuart Charlton <[EMAIL PROTECTED]> wrote: > > > > > > > > --- 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).
What would one of those media types look like? > > > 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. +1 > > 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. Its not that hard to understand (I think I'm there) what I'm beginning to realise is just how immature it is as an approach for the enterprise. > > 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. Is there another possibility, namely that message exchange actually works so why change? There is a fascination in IT with having the theoretically "best" approach rather than just one that is "good enough". If the current approach is successful (which it is) then what is the justification for change? > > > 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.) So there would be quite a bit of upfront design required to achieve this end then? I'm not disagreeing but you might want to have a chat with Jan. At the end of this will we have something like "app/invoice" as a media type ? > > And we would need to extend browsers and/or introduce new kinds of user > agents to understand these new media types. I'd say it would be user-agents more than browsers as much of this is machine -> machine rahter than machine->human. > > 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. As are the message based ones for vertical industries.... > > 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 ;-) I hope that actors are still important as without them there is no reason for anything to exist... Back in early 2001 I was able to link a .NET shop with a Java shop and a legacy set of systems. That message exchange approach and API approach worked really well. IIABDFI > > > 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. So given that REST is very early in the standards area and has none of the support that SOAP/WSDL had in 2000, why will it succeed? > > Cheers > Stu > > __________________________________________________________ > Cheap talk? > Check out Yahoo! Messenger's low PC-to-Phone call rates. > http://voice.yahoo.com >
