[steveklabnik]

I agree that many services are simply CRUD wrappers. That doesn't have much to do with the nature of the architecture Fielding proposes.

I would be interested in some citations from Fielding which demonstrate that RPC is its organizational principle. I don't think they're there, though.

[beamatronic]

I'm surprised someone hasn't embraced the idea and built the ultimate generic CRUD wrapper

[steveklabnik]

They often fail. See ActiveResource, for example.

[mantrax6]

Fieldman's work doesn't exist in vacuum. He talks about HTTP, and HTTP has the verbs it has. It's hard enough to find consistent behavior in HTTP servers and proxies with "PUT" and "DELETE" let alone anything else. But even ignoring that, the verbs the spec talks about are limited. And that's a big problem.

As for RPC, essentially any communication between machines is a RPC. It's message passing ("call") and if the message arrives on the other end it's processed by a message handler ("procedure").

No server can just reach into another server's RAM and get or modify a resource directly. The interaction happens entirely by the will of the message receiver, and in exactly the way the receiver wants (not the sender).

So if we'll be building everything on an appropriate abstraction, it better match what really happens (messages, message handlers) and not some wishful thinking abstraction layered on top (resources, resource modification).

RPC is not REST's problem. The problem is the limited commands (PUT, POST, DELETE) and the single possible query type (GET) that we need to work with.

When a payment gateway has to represent a simple "process payment" command with a series of bogus abstractions like a "POST /payment/transaction/new", you know REST is the wrong tool for the job.

[steveklabnik]

> He talks about HTTP, and HTTP has the verbs it has.

Sure, but REST is not HTTP. Yes, it was created to describe the architecture of HTTP, but you can do REST over other protocols, and even HTTP is not truly RESTful. Indeed, Fielding's thesis devotes an entire section to this: http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluatio...

> and proxies with "PUT" and "DELETE"

This is due to the HTML spec, not anything else. In fact, this was almost changed in HTML5, but the problems with adding arbitrary verbs to HTML.FORM weren't adequately addressed. You could make that case, if you felt you'd solved the problems.

> As for RPC, essentially any communication between machines is a RPC

This characterization of RPC means that _everything_ is RPC, which means it's not a very useful way to compare architectures.

> The problem is the limited commands (PUT, POST, DELETE) and the single possible query type (GET) that we need to work with.

HTTP != REST. That said, something very similar to this is called the 'uniform interface constraint,' and is definitional to REST.

By the way, HTTP can have extension verbs too, so you're not actually limited to that.

Anyway, you still haven't shown me how Fielding's REST is RPC, or at least, in the way that software architects talk about RPC. http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluatio... may be instructive.

[mantrax5]

Regarding RPC, you're right, I guess I'm not quite following the classical understanding of it. I tend to work with actor systems, where everything (in-process or intra-process) is message passing, so I tend to see the message layer first, and anything else merely a protocol implemented on top of it. Hence my response.

As for HTTP, if HTTP itself isn't truly RESTful, the only protocol I've ever seen REST implemented on, I'll have to resign from this debate, because it becomes completely abstract.

I hope the right protocol comes along to show us what REST might really be.

I'm spotting a bit of a pattern in REST supporters, where if some understanding of REST is found to have faults, it's called "not truly RESTful". Reminds me of how Agile failures tended to be explained as "not truly Agile"... but that's another story.

I judge a system by the implementations, not by the theory. If REST is this beautiful unattainable ideal that almost no one can truly implement, I tend to think the fault doesn't lie with the implementers.

It's quite likely REST simply has very few applications itself, but the applications have the potential to become all-encompassing (like the web itself). But in this case the issue remains REST is not suitable for 99% of the services people expose on-line, as each of those services has a specific scope and application, where REST's "network effects" of uniform resource interface and so on don't apply.

[nandemo]

See CoAP (Constrained Application Protocol).

https://datatracker.ietf.org/doc/draft-ietf-core-coap/