Re: Re: GET vs POST
Hi Paul, Paul said: > That's not true. If the client wants, it can do a transformation on the > new one. This is no easier nor harder than sending the transformation to > the server. When you send a "template" with "placeholder queries" you > are just sending a simplified transformation. You're asking the server > to do the client's work for it but there is no real benefit. Didier replies: True, the client can do that. However, the client will have to learn the provider's format in order to transform it. It we got a common placeholder format, then we would have only one thing to learn , otherwise, we have to learn several formats. So the benefit is that we have to learn one language (the placeholder query rules) and not several set of languages. But yes, in the actual status quo, the client may perform the transformation on the client side and would potentially have to learn a new language with each new trading partner. Paul said: >> The client needs to know the query placeholder names and semantics. This > is the same as merely getting back a document with the placeholder names > as keys and associated values and doing the templating on the client > side. Didier replies: The difference is that you do not have to learn a plethora of languages (form the provider point of view) only a single language, the one of the placeholder query. Didier said: > > Ex: > > case 1: GET method > > Actual format is RDF and the client perform a GET with param to get the > > document. Fine for RDF. > > A new format has to be supported for instance topic maps, the the provider > > has to update the app or create a new one (if we are still using the GET > > method) Paul replied > That's simply not true. The client can do the RDF to topic map > translation on the client side as easily as they could on the server > side. Didier replies: yes the client can do that. And potentially the client has to learn a language per trading partner. Not a big productivity gain. Didier said: > > case 2: POST method > > Actual format is RDF, the client perform a POST with a document including > > placeholders (and rules specifying how to encode the returned elements). The > > provider is not aware of RDF, just the placeholder rules. Paul replied: > The placeholder rules must be negotiated between the builder of the > client and server. This is no easier nor harder than negotiating the RDF > vocabulary. Actually it is harder, because the client may need > Turing-complete "placeholder rules" and that is a security threat. Didier replies: Off course if the placeholder rules are ad hoc, nothing is gained. If the placeholder rules are standardized then you have leverage: one language to learn in order to adapt to different formats. There is, I think, one potential problem with the approach and you raised the issue. The question derived from this issue is: "Do we need a Turing complete language for this task?". There is some research to do but potentially, a query language that includes loops may fulfill a lot of needs. But I agree, the query language's versatility or lack of can be the make or break of the concept. > Didier said: > > If we just look at the actual situation with Google, if they want to satisfy > > allo groups they need to support a REST like interface and a SOAP like > > interface, then also RDF, topic maps and tutti quanti. They don't because it > > means more cost for them. By extending the concept of template based queries > > we resolve this problem (until we find limitation to this solution and then > > again we have to seach for a new better one). Paul replied: > That's not true. They can support just RDF and then ask people who want > topic maps to do the conversion on the client side, or vice versa. Didier replies: So this is what Google do with SOAP doesn't it? (provide a single interface and ask everybody to either use it or adapt to it by locally transforming to their own format). So why they should publish with a REST like architecture? :-) See, each group/community wants the provider to support their pet API/architecture. Two options, we create/design an architecture allowing variance and economical ways to satisfy that need for variance or we do like Google does, satisfy what they think is the biggest market share and tell the others to "adapt" (by performing a local transformation to convert into their own format). The monkey is on their shoulder now, they can use a style sheet to transform the provider's format. <End of demonstration> 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