On Sep 19, 2005, at 4:05 PM, Gregg Wonderly wrote: > 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. >> > > But, the way that results are returned, as well as the formatting > of those results will create dependencies within your > client software.
Yes, the clients depend on - being able to parse the message - understanding the semantics of the message type The point is that it is much easier to handle evolving semantics as document transformations than as API integrations. RESTs architectural property of extensible client capabilities (e.g. XSLT, JavaScript) even enables the server to send the neccessary transformation code (given the components have been implemented up front to handle this kind of evolvability scenario). Suppose the (XSLT capable) client implements XML DTD Foo-V1 and is perfectly happy with the server sending all those Foo-V1 messages. At some point, there is massive integration going on in some other part of the system, causing changes in the domain semantics and eventually Foo-V1 to cease to exist. Content negotiation will show the server, that the client cannot handle the new Foo-V2 (obviously so, because the implementation depends on Foo-V1). But given the XSLT capabilities of the client, the server can send Foo-V2 messages with a reference to a Foo-V1 -> Foo-V2 XSLT (which has been created in the course of the integration work) and the client will just be fine. Evolving domain semantics without a need to even think about where Foo-V1 clients actually havebeen deployed. How can it get any better than that in networked systems and EAI? > There is no independence from the *implementation* here. The > protocol and all of its limitations are > embedded in the applications protocol. Yeah....and because that is so detrimental to evolvability, your browser can do all this SVG, Java, JavaScript, Flash, VRML....magic, right? Jan > > Gregg Wonderly > > > > > ------------------------ Yahoo! Groups Sponsor -------------------- > ~--> > Get Bzzzy! (real tools to help you find a job). Welcome to the > Sweet Life. > http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/NhFolB/TM > -------------------------------------------------------------------- > ~-> > > > Yahoo! Groups Links > > > > > > > > ________________________________________________________________________ _______________ Jan Algermissen, Consultant & Programmer http://jalgermissen.com Tugboat Consulting, 'Applying Web technology to enterprise IT' http://www.tugboat.de ------------------------ 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/
