On Sep 19, 2005, at 4:17 PM, David Forslund wrote: > If the interface is the same how do I know if one is asking getAge or > getInvoice?
You donot need to know. The client asks 'send me a representation of your state' and 'please send it in this and that format of you can'. It is upto the client to extract the Age property from that state representation. Consider how a search engine gets the titles of the indexed documents: the uniform API+HTML semantics make it possible without a specialized http://foo.org/myDoc.html->getTitle() method. Using RDF as a representation format takes this to the extreme because the dependency on a particular MIME type goes away and clients can just extract the triples they want from the RDF representation of the objects state. No matter what tripples you add to the representations in the future, your clients will never break. > What about other operations besides > get and set? What about "Find all individuals with a last name that > sounds like this name?" IMHO, querying (as opposed to browsing/discovery) in a distributed environment makes only sense if you use dedicated search services (like Web search engines). They expose themselves as indexable resources[1], that you can query e.g. like this: GET http://service.org/search? prop=foo:lastname&operator=SOUNDEX&pattern=Moo > 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. See Mark's RDF Forms[2] for this purpose. > 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. Based on my own experience, I admit that understanding the whole value of a uniform interface (and the other REST architecural constraints) propably takes a significant amount of time (2 years for me). For me the key to the final aha-moment was looking at the whole thing in terms of evolvability, especially the question of how to avoid the need to touch components of a distributed system again once they have been deployed. REST is targeted at this and if you OTH know that your semantics will never evolve, a uniform API is overkill for you. Maybe this POV helps in understanding the issues..!?!? Jan [1] http://www.markbaker.ca/2001/09/draft-baker-http-resource-state- model [2] http://www.markbaker.ca/2003/05/RDF-Forms/ > > 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 > > > > > > > ________________________________________________________________________ _______________ Jan Algermissen, Consultant & Programmer http://jalgermissen.com Tugboat Consulting, 'Applying Web technology to enterprise IT' http://www.tugboat.de ------------------------ 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 <*> 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/
