[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: GET vs POST


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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.