[
Lists Home |
Date Index |
Thread Index
]
Hi Paul,
Paul said:
> My point in the article I referenced is that the web is a system with
> its own data model. If you want to get the full benefit of the Web you
> need to map things into that model in the same way that you only get the
> benefit of SQL by mapping things into the relational model. The web is
> flexible enough that you can hack your way around the model (much easier
> than you can in, e.g. SQL) but then you will run into limitations like
> the SQL encoding issue.
Didier replies:
If we refer to the Uniform Resource Locators then each resource is
identified with a "location". if obtaining data/content means that we are
only allowed to obtain it with an HTTP GET (REST presumption) through a URI,
for instance a locator (i.e. a URL), then if we use query templates to
obtain content we will have to perform two operations:
a) POST the template to the server
b) GET the result from it
I guess that people where responding with two classical human reaction to
this:
a) resistance to sleep in a procrustean bed. Said differently: to be too
much constrained by an architecture when this latter is costing more than
other ways of doing things
b) speaking of costs, the Maupertuis principle says that people will seek
the most economical solution (in the long run as economist like to say).
The most economical solution for people was to use an HTTP POST since it
involves a single operation (request-response) and a simple server
implementation (a lot more simple as you can presume than with a dual
operation). You send the template and get back the document. All in one
single operation.
As people saw that SGML when applied to the web was too complex (this is why
XML was created), it is possible that the Web architecture as proposed by
REST is also too restrictive and leads to more complexity or non-economical
ways of doing things. Off course the political arena will polarize people
around one or the other solution. Sciences and technology is not free of
politics (after all humans created both and humans are political creatures).
Nonetheless, people having to resolve concrete problems will always struggle
with the Maupertuis principle and therefore will resist being forced to fit
in a procustean bed (this implies that they will try to seek a solution as
did the group who created XML when constrained by the SGML architecture).
I agree, to use SOAP everywhere is not the best solution. To try to fit
everything to the REST architecture is also not the best solution. To
finally propose HTTP guidelines is a good solution but is a bit too late
since millions of applications are actually dependant on other ways of doing
things and since W3 is not a Procrustean tyrant, it can't cut our legs to
make us fit in the prescribed bed (i.e. solution). Especially after so many
years the specs wehre published and after millions of applications did the
"mistake" already. It is what we could say is a de facto solution to a
problem(like others say its a de facto standard).
SOAP is actually using HTTP as a transport. Maybe this is not a good
solution too. Maybe people would be satisfied if it got its own port (not
the port 80 dedicated to HTTP). Maybe *this is the real issue*. SOAP is
using HTTP as a trojan horse and maybe is perverting its original
dedication, threfore it should have its own port. Otherwise, it is an HTTP
application and thus, the role of POST and GET has to be re-think in the
light of actual usage (i.e. common practice - to think as common law or
common sense).
So what about having SOAP to get its own port and therefore be a real
transport protocol, this time based on XML instead of the format proposed by
internet messages (like SMTP, SIP, HTTP, WEBDAV, etc..).
cheers
Didier PH Martin
|
