[
Lists Home |
Date Index |
Thread Index
]
Hello Paul,
First I renamed the thread since we are no longer taking about SOAP bu tmore
about the limtation of GET and how PUT could be useful to *get* data or to
perform more versatile requests.
Didier said:
> Not necessarily, for recurrent usages, the query template may be stored on
> the server and then invoked with a GET. Otherwise with a single POST. From
> this we can deduct that to use the GET method, we have to store something
on
> the server prior to the transaction. In contrast, the other method (i.e.
> POST) does not require that and ad hoc transactions can be completed in a
> single stateless operation.
Paul replied:
> I personally feel that it would be simpler to design the system so that
> it chooses one model or another. Either queries are resources that live
> for a period on the server or they are not. Otherwise your clients and
> servers need to negotiate which model is acceptable to each when they
> first encounter one another.
Didier replies:
I agree. I would be a lot simpler.
Didier said:
> > ... The server's contract is reduced to fill the placeholders,
> > not to impose a full document structure or its view of the world to the
> > clients. Now if the placeholders are expressed in a standard way, we
gained
> > something, otherwise I agree, we gained very little in the process
(hoops I
> > forgot to say that the placeholder are to be standardized either as de
> > facto, consortium recommendation, ISO standards or as per industry
> > convention).
Pau replied:
> I am completely not understanding this process.
>
> Client sends the server:
>
> <myformat>
> <abc><temp:template select="$foo"/></abc>
> <def><temp:template select="$bar"/></abc>
> </myformat>
>
> If it has already negotiated with the server that "$foo" and "$bar" will
> be available then it would take no extra effort for it to work with a
> document of the structure:
>
> <blah>
> <foo>...</foo>
> <bar>...</bar>
> </blah>
>
> or even:
>
> <values>
> <key name="foo" value="..."/>
> <key name="bar" value="..."/>
> </values>
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). 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.
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)
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.
A new format has to be supported for instance topic maps, the client perform
a POST with a document that includes placeholders(and rules specifying how
to encode the returned elements). The provider is not aware of the topic
maps specifications, just the placeholder rules.
The difference between the two methods:
a) no delay in terms of supporting new domain languages or new document
structure.
b) if there are no delays then there is a potential impact on satisfaction
or experimentation of new formats.
c) more versatile and less costly for the provider
d) if less costly then we are taking now of reduced developement cost, an
improvement on the actual situation that in order to satisfy the different
groups we have to add more and more APIs.
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).
Conclusion: an architecture based solely on the GET function may lead to
additional cost, delays and frustrations. The GET method has limits if we
add to the real equation:
a) development time
b) capacity to satisfy the different groups, ecosystems and their pet API or
document format (as long as the docuemnt format is based on XML)
c) versatility
My take, people used the POST function they way they are using it because
they got good reasons. We should listen to them instead of a slap on their
hand saying that this is not conform to the specifications. They may have
used POST simply because GET and indempotency is *in reality* a mirage since
we have CGI applications and caching. Its has limits and cannot fulfil all
kinds of request. So instead of saying to these people how they did wrong
why don't we simply ask them "why was that useful?".
cheers
Didier PH Martin
>
> > Also, the templates offer a certain processing economy. If the entire
world
> > has not standardized on a business transaction (i.e like edifact or X12)
or
> > if two business partner operate within two different ecosystems (i.e.
> > different business document formats), then this could be used to
minimize
> > the transaction cost. Notice that the client obtains a track record of
the
> > transaction or that a middleware can keep track of the transaction as a
> > complete document (Ex: an account statement).
>
> I believe that the level of standardization required is exactly the
> same. In order even to *ask* for the values, (in this case $foo and
> $bar) you will have by necessity learned the details of the service's
> data model. Furthermore, by doing the transformation on the *client* you
> can use a complete, Turing complete language like XSLT or DSSSL or
> Python. But when you do it on the server, you are necessarily restricted
> to a very restricted language which in my opinion will not scale up to
> any kind of half-way complicated system (loops within loops etc.).
>
> What you are describing is like if on today's web we sent a CSS file to
> the server to tell them how they should render the data. Better we
> control the application of the CSS on the *client*.
>
> So I'm going to stick with my answer that templating and other types of
> transformations are, in the web architecture, done on the client side.
> You can of course use HTTP POST (with or without SOAP) to shift that
> responsibility to the server, but I see no benefit.
>
> *Negotiating the templating keywords is exactly as much effort as
> negotiating a shared XML vocabulary*
>
> > Now, you would convice me of the merits of the actual "a priori web
> > proposal" with more complex business applications that the ones
mentioned.
> > Paul you took the socratic position to let me express my opinion, now
let me
> > take that position and ask you how you would resolve the use case I
> > mentionned in the last message.
>
> In my model, the server would be stateless. The template would live on
> the client. The server would use HTTP's content negotiation to present a
> menu of various vocabularies to the client. If the data output is simple
> enough to support your replacement model, then it is simple enough to
> support a key/value pair model as I described above. This can trivially
> be used to do the transformations on the client side. All of the
> server's information resources can remain addressable.
>
> >...
> > In the case of the google example, they could have picked a solution a
la
> > Moreover [1] and provide all the formats suited to the clients needs[2]
or
> > simply let the client submit their format and then fill the
placeholders. If
> > you want to standardize the transaction (or at least follow a consortium
> > recommendation not an international standard), then Google could use
XSLT
> > templates and present their information universe as an infoset. The
template
> > being resolved on the server side, the document is now formatted the way
you
> > want (SOAP, RDF, topic map, semantic links, etc...) This way, if a new
> > format comes out of the mind of creative people it is automatically
> > supported by the information provider without additional cost or
development
> > delays. The information provider doesn't necessarily have to know the
> > format's existence. Otherwise, we are trapped with the same problem as
we
> > encountered during the big iron era: development delays.
>
> I'm sorry, I completely do not see how moving the transformation from
> client to server changes any devlopment delay issues. Let me give a
> concrete example.
>
> Let's say the server has news syndication information. Let's say it
> supports XMLNews but not RSS. Your solution is for the client to push a
> document like this:
>
> <rss>
> <title>$title</title>
> ...
> </rss>
>
> This requires the client and server to have negotiated what "$title"
> means. If they have already negotiatied this then they could have just
> agreed that the server would return:
>
> <our_shared_ml>
> <title>...</title>
> ...
> </our_shared_ml>
>
> Or maybe they use XPaths. If so, then what are they using XPaths *into*.
> Whatever that thing is, it is the real resource and should just be
> returned in XML.
>
> Let me be concrete again. According to your theory, function A is more
> flexible and adaptable than function B:
>
> def A():
> return arg1, arg2, arg3
> print A()
>
> def B(template):
> return template % (arg1, arg2, arg3)
> print B("Value 1: %(arg1) 2: %(arg2) 3: %(arg3)
>
> But they are *exactly as flexible as each other* because you need to
> know about "arg1", "arg2", and "arg3" *anyhow*. Therefore it is just as
> good to return the data as close to "raw" as possible and let the client
> do the templating.
>
>
>
> Paul Prescod
>
|
