My question is what does REST really bring to the table. It just pushes the problem to another area (the document must contain the "methods" rather than the "interface"). The argument for REST as I understand it is that deploy and modifying interfaces is "harder" than deploying the interface through a document. Unfortunately, I believe this has the side effect of having a different interface for every "document" that is used. This results in poor interoperability, since I may have to change the "document" for every service instance that I want to connect to. One needs to "standardize" the methods in some form in order to have interoperability. Which way is "harder" may be in the eye of the developer, but the work is the same in either case. So the issue isn't "begrudging REST's ability to constrain the interface" but rather to say that REST doesn't really express the "verbs" of the interface which must be expressed in some other way. The way I deal with interfaces is to have the "verbs" in the interface, and the "nouns" in the data. That way it is clear that if you want to do something different with the data, you use a different interface. Semantically one needs to express the "nouns" and the "verbs" to be used regardless of how this is implemented or expressed.
Dave Mark Baker wrote: > > Hi David, > > On 7/10/06, David Forslund <[EMAIL PROTECTED] > <mailto:forslund%40mail.com>> wrote: > > Mark, > > I don't understand your answer. How does defining the operations > > in "a document" make it any easier to deploy the application? One > > has to agree on the semantics of the document to understand the > > data and the operations. This is basically equivalent to a UML > > model that must be sent over the single interface. (data + methods = > > objects). > > What semantics are used to express this? Greg's point is that one has to > > do the same work in either case. The debate then over which is an easier > > way to express the semantics (and then to implement them). > > I'm not exactly sure what you're asking there, because you use > "semantics" in a manner inconsistent with how I'd use it. But I don't > understand how you can begrudge REST's ability to constrain that all > interfaces be the same. > > I mean, feel free to believe that this constraint comes at a large > cost if you must (e.g. makes the resulting system only good for > transferring HTML to humans using browsers), but you can't say that > REST doesn't do something it's *defined* to do. > > Mark. > > __._,_._ ------------------------ Yahoo! Groups Sponsor --------------------~--> Something is new at Yahoo! Groups. Check out the enhanced email design. http://us.click.yahoo.com/SISQkA/gOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
