Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: GET vs POST
 Didier PH Martin wrote: > >... > > Didier replies: > Yes, the main point is that the client provide the structure, the server has > only to support the template placeholder queries not the full document > structure. For instance, let's say that tomorrow, a new XML format is > popular. Actually, the client will have to wait that the provider update the > app or write a new one to support the new format (with a GET request). 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. >.... But > in the case of the client being able to send the new format that includes > the query placeholders, the provider has noting new to develop and the > morning after the new XML spec is out, the client can perfrom its request. 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. > 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) 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. > 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. 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. >... > 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). 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. Paul Prescod 
|
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
|
|||||||||
