CHAPTER 5: Representational State Transfer (REST)

I've about had it reading discussion after discussion on the topic of REST between people who haven't read the damned paper.<p>Here is my takeaway:<p>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.<p>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.

So in reading that chapter it seems like REST can be boiled down to these statements:<p>1) Client-server<p>2) Stateless<p>3) Cacheable or noncacheable constraints<p>4) Uniform interface<p>5) Abstracted so that you can only see the layers directly in front of you.<p>6) Client side code, e.g., Javascript<p>7) (Potentially) Late binding of reference to representation<p>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."<p>But a lot of what is described as REST imposes additional constraints that I don't see in this description. Did I miss something?

Shouldn't that be RST?