Sam Ruby's Learning to REST and Exercise left for the student posts both point to Adam Bosworth's Learning to REST post. Along with the three posts, there are a number of excellent comments and clarifications about REST architecture.

Other links of interest, mentioned in the various posts and comments:

RDF Forms, by Mark Baker.

Reliable delivery in HTTP, by Paul Prescod.

Hyperlinks matter, by Jon Udell (from May 2002).

Service-orientated-architecture, by Sean McGrath.

I am trying to design the iCite net (specifically the iCite Containers which are like iCite web servers) to support both REST and RPC interfaces. What has been interesting for me to consider is at what layer in the code the "R" (Remote) should go away and only "procedure calls" are left.

At an extreme, if every method can be remote, could every method call be RESTful? If some methods will be local or remotely accessed by known end-points, should those use procedure calls? Should those be exposed as RPC?

So, one approach that seems interesting at this point is thinking about parallel interfaces for both REST and RPC styles. When the system functions in a more distributed fashion, perhaps the REST interfaces are best to use. When the system functions in a more local or controlled end-point fashion, maybe the RPC interfaces are best to use.

But, I get the feeling that for some interactions, one or the other style will be so much more ideal, that those interactions will not be supported evenly across both styles.