REST vs. RPC exploration

This is a technical post regarding something approaching a technical Holy War; if you're here for the internet stuff, please ignore the following.

Paul (Snively) says, This is the part I find baffling: someone as smart as Roland finds REST "harder to understand" than RPC! I'd be very interested—no sarcasm, as Dave would say—in hearing some comments about that, as I want to gain a better understanding of the issues so that my own ignorance doesn't become self-defeating in RPC and REST discussions. (Check the context if you're really interested in following this.) I had been conversing a bit in his comments, but I wanted to get this more out in the open.

I've only really been exposed to RPC, and I've got a fairly firm grip (IMHO) on why XML-based RPC sucks. (All software sucks (to put it politely)... the question is always whether the benefits outweigh the costs. In the case of XML-based RPC, I'd say the answer is clearly that the benefits are sufficient; the debate here seems to be whether REST has a better cost/benefit ratio; perfect holy war fodder!) I know REST mostly by the Prescod article. Let me explore the issue:

  • First, is this an example of REST? (Perhaps I stumbled onto it on my own already.) You may need to view source that page. It takes the parameters on the URI and outputs Frontier table XML based on the args. I think that it is, I just want to check to make sure I understand.
  • REST easier then RPC: REST does seem easier to understand once you understand it; REST is what you're more likely to do as a one-off solution to this problem. It's an awfully fancy name for an awfully simple answer.
  • What exactly is the primary bone of contention here?
    • Is it the URI issue? Would REST advocates be happier if SOAP calls could be encoded onto a URI, but still get the exact same XML back?
  • Is it the XML complexity? That complexity solves problems for some people. If REST wants to solve those same problems, it must use a similarly complex encoding. If it doesn't need to solve those problems, then you can go with XML-RPC or some hypothetical simpler RPC standard. This issue seems tangential, as either RPC or REST could use simpler or more complex encodings, without changing the essence of the debate.

The more I think about the whole thing, the less I understand the conflict. In the end, the real differences between "RPC" and "REST" seems to be exactly the differences between GET and POST with HTML web forms, where one uses the URI and one feeds the data through the HTTP request.

The whole encoding bitchfest seems to me to be a bugaboo, because the arguments that Paul Prescod uses to criticize SOAP's complexity aren't arguments against "RPC", they're arguments against SOAP in particular (which in most cases I largely agree with, with the caveat that it matters to some people; just not me). I don't think the encoding issue should come up in REST vs. RPC at all; it doesn't seem fundamental.

So this is my current understanding: Seperate out the issues in the debate, which seem to be encoding, and whether params should be on the URI. (I just re-skimmed Prescod's piece, and I think that covers the objections. The stuff about "typing" is an encoding issue.) Discard the encoding as a irrelevancy. That leaves the URI issue. That's a stupid point to get hung up on. And I think that's my summary of this whole debate: "That's a stupid point to get hung up on."

But I am interested in hearing counter-points, or places where I may be oversimplifying.

Update (about an hour later): I see casting the debate in terms of GET vs. POST has been done (more or less). I did not see this article before writing this post; I guess I feel validated, if redundent.