

CHAPTER 5:  Representational State Transfer (REST) - collint
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

======
collint
I've about had it reading discussion after discussion on the topic of REST
between people who haven't read the damned paper.

Here is my takeaway:

There isn't much to do with URLs in here. One URL, One resource (collection
counts as a resource). Talk about URLs all you want, there can bee good
resource identifiers and bad ones. But REST doesn't care as long as you don't
break the golden rule.

REST is an RPC system. You call remote procedures, GET, PUT, DELETE etc. on
remote resources. You are probably not smart enough to do better than what
naturally emerged as HTTP. Behemoths and industries have tried. But HTTP won,
and it will win again.

~~~
AffableSpatula
Sorry that's wrong; neither REST as a style or HTTP as an implementation are
RPC. One of the key components of REST is Layering which is made possible
because REST is distinct from RPC. This is covered in the dissertation:

[http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluatio...](http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm)

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.

~~~
davidmathers
Shorter RTF: The client might GET from a cache, so obviously GET isn't a
procedure running on the remote server.

~~~
AffableSpatula
Yeah, caching is a type of layering

------
kenjackson
So in reading that chapter it seems like REST can be boiled down to these
statements:

1) Client-server

2) Stateless

3) Cacheable or noncacheable constraints

4) Uniform interface

5) Abstracted so that you can only see the layers directly in front of you.

6) Client side code, e.g., Javascript

7) (Potentially) Late binding of reference to representation

8) "The connector interface is similar to procedural invocation, but with
important differences in the passing of parameters and results. The in-
parameters consist of request control data, a resource identifier indicating
the target of the request, and an optional representation. The out-parameters
consist of response control data, optional resource metadata, and an optional
representation."

But a lot of what is described as REST imposes additional constraints that I
don't see in this description. Did I miss something?

~~~
collint
I tend to agree with you, but don't just take it from me:
<http://tech.groups.yahoo.com/group/rest-discuss/message/6735>

I don't think it's fair to say the original dissertation is the final word on
REST, but I do think almost all of the discussion on REST is way off target.
It feels like almost all the discussion is about the construction of URLs.

REST has become a buzzword, people use it just to project credibility.

~~~
T-R
I have a lot of respect for him, but it's pretty disappointing to see him so
opposed to doing things that would bring more clarity to those trying to
understand his work. This is at least the third quote I've seen of him blowing
off the idea of giving examples or more documentation. It's further
disappointing to see "that document is my dissertation" juxtaposed with "I
sometimes need to expand on the terse explanations provided in the
dissertation, because I was in a hurry when I wrote it".

------
LilValleyBigEgo
Shouldn't that be RST?

