I wouldn't even want it to talk to me (or even know about me) if it wanted to getInvoice instead of getAge. Having to respond to random unrelated requests is a problem and increases overhead to the server. If one is dealing with documents only, it is simplified, but still needs to have relevant content and context. If everyone uses RDF, then that constraint could easily help in the exchange of information, but that is an additional constraint that everyone must adopt. Who "own's the semantic elements in the RDF document? How do I know that the word "invoice" isn't the translation of the word "age" in some other language?
Jan Algermissen wrote: > > 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. I don't see how it knows what a title is. This is a very ambiguous request. > > 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. I disagree. What if you take triples away or change the meaning of the triples? > > > 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 I understand that one can use a URI to specify a method and the arguments to specify the arguments. Where do I discover the "meaning" of the response? The deployment of a URI isn't that different than exposing a method on an object. > > > > 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. The RDF Forms seems to add the necessary context one needs for some applications. Seems like just another way to add the complexity required for true distributed computing. Certainly nothing wrong with this but it requires yet another standards agreement. I don't see how this simplifies anything. > > > 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. But you may need to touch the system if the encoding of payload changes, which it could easily with the rapid evolution of standards. Can your system deal with ebXML? If not, what do you have to do to make it understand ebXML. Then what about ebXML..n? This requires code changes and updates. I don't see how this approach simplifies things. If an interface changes, it can be evolved just as easily (essentially the same work) as changing the form of the document to be handled. So I guess I'm missing something, but basically distributed computing has a certain amount of necessary complexity and one can move this around to suit different styles, but basically one has to do the same amount of work. I don't understand why deployment of an API with a registry mechanism which has existed for many years isn't sufficient or worse than what you suggest. Dave > > 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 <*> 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/
