From: Roy T. Fielding (fielding@kiwi.ICS.UCI.EDU)
Date: Fri Mar 17 2000 - 21:55:02 PST
I've never understood why people seem compelled to think of HTTP
as an RPC mechanism just because it involves requests and responses.
What distinguishes RPC from other forms of network-based applicatioon
communication is the notion of invoking a procedure on the remote
machine, wherein the protocol identifies the procedure and passes it
a fixed set of parameters, and then waits for the answer to be supplied
within a return message using the same interface. RMI is basically
the same thing, except that the procedure is identified as an
(object, method) tuple rather than a service procedure. Brokered RMI
adds name service indirection and a few other tricks, but the interface
is basically the same.
What distinguishes HTTP from RPC isn't the syntax. It isn't even the
different characteristics gained from using a stream as a parameter,
though that helps to explain why existing RPC mechanisms were not
usable for the Web. What makes HTTP significantly different from RPC
is that the requests are directed to resources using a generic interface
with standard semantics that can be interpreted by intermediaries almost
as well as by the machines that originate services. The result is an
application that allows for layers of transformation and indirection
that are independent of the information origin, which is damn useful
for an Internet-scale, multi-organization, anarchical information system.
You won't find anything like the notion of a "resource" in the earlier
RPC mechanisms. They were all defined in terms of language APIs,
not network-based applications.
Lots of people do crufty things via HTTP that do not share the advantages
of the standard interface. I don't care. Even more people develop
sucky distributed applications that rely on POST to mimic procedural
invocations, the more formal of which are XML-RPC and SOAP. Using an
inefficient RPC mechansim only makes them slightly more sucky than
they would be otherwise -- RPC just isn't a good mechanism for making
requests across trust boundaries.
I have no clue why people think it might be important for one protocol
to "win" over another. I don't use HTTP for things it doesn't do well.
One of the things it does well is allow access to remotely stored
messages, so I'm not surprised that people use it for mail -- Alex
has been advocating that for ages. I don't use HTTP for mail, but
that is primarily because what I really need in an MUA is something
that can delete all the messages I want to delete without deleting
the ones I want to read (or save). Who cares about the transfer protocol
when every single mail client sucks for high-end usage?
The funny thing about HTTP is that everyone assumes that it is a
static protocol now that it is widely deployed and used for all these
funky things. Hah!
....Roy
This archive was generated by hypermail 2b29 : Fri Mar 17 2000 - 21:56:20 PST