[
Lists Home |
Date Index |
Thread Index
]
Tim Bray wrote:
> It
> seems to me profoundly profoundly silly to assert that the RPC model of
> fetching information using a service name and some name/value argument
> pairs is dead. It also seems profoundly silly to assert that the RPC
> model is the be-all and end-all.
I'm not saying that the model is dead, just that the assumption that
there is no serious requirement for query parameters that are too
complex to be URL-encoded as a list of name-value pairs is no longer
valid. I think I can see the advantages of having these queries
represented in a document-embeddable, idempotency-assumable form, but
unless someone provides a solution which provides these characteristics
for complex queries, then people will just use POST instead. Time will
tell, but at this point I'd be willing to bet a nice bottle of wine on
this outcome being apparent within the next six month
> The important difference is that that the RPC model, for safe/idempotent
> operations, can in principle be exposed as a URI. In practice, it can
> be done cheaply and easily (see my proposal over in www-tag). If it
> can be done, it should be done. Those who fail to see the benefits of
> placing the maximum possible amount of information in URI space just
> Don't Get It and have apparently slept through the last decade.
Your proposal is interesting and appears to me to provide roughly the
same functionality as the existing GET support in WSDL.
But I'm interested in passing schema-valid XML blocks as query
parameters, or representations thereof. Your proposal doesn't help much
there.
Are you really comfortable asserting that there is and will be no
substantial requirement for safe/idempotent operations which have
parameters of context-sensitive complexity rather than of FSM
complexity, which I think is what it boils down to?
If not, why don't we try to come up with a solution which meets your
requirements?
Francis.
|
