Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: GET vs POST
 Hi Paul, Paul said: > Didier, if the variables are not standardized then a client that talks > to 500 services must code a 500 "template documents". Do you agree or > disagree? > > Therefore the cost of integration of clients and servers scales linearly > with the number of services. Either this is an acceptable situation or > it is not. If it is not then you need complete standardization -- you > must standardize the variable names. Didier replies: Yes I agree, due to a lack of standardization you'll probably have to create as many queries as the number of services you want to connect to. My solution can only reduce the provider's costs not the client costs. The client's costs are reduced only when the interface (parameter list, query or whatever) is standardized. For instance, if all search engines normalize on RDF or topic maps then they have reduced the access cost, if each one provide their own SOAP interface or their own URL's parameter list then the client's adaptation cost are still high. Paul said: > That is the case *anyway*. You admit that every client needs to conform > to the distinct variable names created by each different server vendor. > In other words: "my way or the highway." There are only two options: "my > way or the highway" or _complete_ standardization so that "my way" and > "your way" always align. Standardizing merely the templating format > still forces the client to conform to the whims of the server: "oops, we > decided to change a placeholder name today" AND breaks easy addressing > AND moves compuational effort from the client to the server. > Didier replies: You're right the only best solution that could resolve this "prisoners dilemma" is some cooperation between the provider and the client and therefore to standardize the interface and the returned format. However, the current trend between both the client and the providers is a state of "non-cooperation" between them. SOAP just re-enforce this issue and URL with param list cannot help too unless, all the providers in the same service class agree on a certain interface. But again, the competition dynamics and Michael Porter five forces are still ruling the marketplace. The vendor still want to play a game of creating barriers of switching to an other alternative service and resist giving up control to the clients by being reduced to a commodity through a single interchangeable interface. Conclusion: REST or SOAP do not resolve the issue. The issue is resolved only if all the providers of a service class support the same interface, it be SOAP or REST based. The main point is not the architectural structure per se but the interface defined and the data returned, both have to be standardized to resolve the "prisoners dilemma". I guess that this is the real issue here. If Google and the other agree on the same interface (i.e. request and returned data) then whatever they use REST or SOAP as the underlying architecture we win, otherwise, we (i.e. the clients) loose. This has been an interesting journey Paul, sometimes we get caught in the technical aspects and forget that without a win-win contract, in a zero sum game someone is a winner and someone else is a looser. What made the web a win-win solution was the fact that, for a moment, everybody (the providers and the clients) agreed on two basic technologies HTML + HTTP. If there is anything that we should lobby for is a common interface whatever it is based on SOAP or REST. cheers Didier PH Martin 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
