If the interface is the same how do I know if one is asking getAge or getInvoice? What about other operations besides get and set? What about "Find all individuals with a last name that sounds like this name?" This type of question needs to be encoded in the payload. If you send this message to my server that only knows "age" (based on some earlier context or "state"?), it can't intelligently respond to the question. One needs to have a way to "register" the server's capabilities as to what it can respond intelligently to. Certainly a registered API is one way to do this. Other ways must be substantially equivalent to this and save nothing in terms of implementation or deployment, since code equivalent to the API must be embedded in the server. The only value I can see in this approach is associated with a failure in the way of registering application semantics so that an external client can discover those application semantics. But this is only a reduction in interoperability not an enhancement of interoperability.
Dave Mark Baker wrote: > On Sat, Sep 17, 2005 at 06:42:33PM -0600, David Forslund wrote: > > If one only as PUT and POST one is severely limited on the type of > > application semantics > > that one can express. Sending all communications over these type of > > "method" calls is > > pretty limiting or requires one to add the application semantics to the > > messages. > > Not at all. Consider that the single method "GET" replaces the need > for all "get*" semantics such as getStockQuote, getInvoice, getName, > getAge, etc ... > > Nothing prevents the *implementation* from varying, it's just the > interface that stays the same, just as getStockQuote can return > both real-time and delayed stock quotes. > > Mark. > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/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/
