|
|
|
|
|
by funcDropShadow
1843 days ago
|
|
This short note seems to be based on the nowadays common misunderstanding that REST means doing RPC over HTTP with Json payloads. At least, according to the work that coined and defined the term REST -- REpresentational State Transfer --, it described an architectural style or pattern to overcome the inherent limitations of RPC. E.g. have a look at Chapter 6.5.2 of Roy Fielding, "Architectural Styles and
the Design of Network-based Software Architectures" [1] to see that why it should not be an RPC mechanism: 6.5.2 HTTP is not RPC
People often mistakenly refer to HTTP as a remote procedure call (RPC) [23] mechanism simply
because it involves requests and responses. What distinguishes RPC from other forms of
network-based application 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. Remote method
invocation (RMI) is similar, 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
very useful for an Internet-scale, multi-organization, anarchically scalable information system. RPC
mechanisms, in contrast, are defined in terms of language APIs, not network-based applications.
Nevertheless, many resources on the web use REST to denote a HTTP-based interface which only uses a modicum
of the ideas of Representational State Transfer. But the above post goes even further from the original meaning
by claiming: The thing with REST, is that at its core, it's basically a RPC (Remote Procedure Call) that we've been
trying to cram in the HTTP protocol.
[1]: https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluati... |
|