It's Like Déjà Vu All Over Again
"You could probably waste an entire day on the preceding links alone. But why take chances? We also give you Paul Snively..." — John Wiseman, lemonodor
I had been conversing a bit in his comments, but I wanted to get this more out in the open.
Thanks, Jeremy! Your comments have been a huge help, and I agree that we should bring them out into the open. Thanks for facilitating that.
BTW, to answer one of your questions in my comments: the principal reason that I use YACCS vs. Userland's comments is precisely for the feature that I can subscribe to my own comments as an RSS feed. So they show up in my news like everything else. Definitely a lifesaver!
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!)
Extremely well put! I think you've especially hit the nail on the head when the discussion begins to revolve around amorphous, fuzzy concerns such as "scalability," because of course scalability is relative. At work, we're in the process of evaluating Message-Oriented-Middleware vendors who hype their products as being able to handle throughput of some 1,500 message/second. A colleague and I ran some numbers after our boss indicated a desire to be able to handle triple our current traffic, and we discovered that we'd need to be able to handle...
...approximately one message every three seconds. As I said to him after doing the math, a carrier pigeon would meet our requirements.
So it's good to be skeptical about relative concerns.
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.
AFAICT, this is a fine example of a RESTful interface.
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.
I think this gets to the crux of the problem: REST is exactly what you'd do as a one-off anyway, so what's the big deal? I think the big deal is precisely that there's one additional issue, namely the handling of structured data, and for that you should use XML.
The other, ancilliary, issue is that if you're going to be hyperconsistent about REST, if someone PUTs a new resource on your server, then your server should suddenly repond to a GET for that same resource. The implication is that all of your URI handling needs to be dynamic. This might be considered an onerous burden that full compliance with REST philosophy imposes.
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?
I can only speak for myself, but in my case, yes. I summarize REST in my own mind as "taking resources and their identifiers seriously," or "making resources first-class," or however you want to put it. Resources can be GETted, PUTted, POSTed, etc. in the general case. Paul Prescod has written about this at length.
I guess another way to put it is that REST essentially visualizes the web as a huge tuple space, and HTTP as very much like the Linda operators on that tuple space. However, I'm well aware that terminology like that is what makes REST seem alien. Maybe a better way to express the same concept is that the web is a huge hash table, and HTTP provides its "get" and "set" operations?
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.
Once again, I think this is correct: REST says nothing about the wire format; Paul Prescod says "if dealing with structured data, might as well use XML," and I agree with Paul.
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.
Yep. Fundamentally, it's really about generality vs. specificity and transparency vs. opacity.
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.
I agree that it's a distraction, with the caveat that, since any RPC mechanism forces you to encode function/parameter names or ordering, that aspect of Paul's complaint is valid. But you're right about this complaint not being 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."
I agree with the assessment that it's not worth arguing about now. But as I've written before, my concern is that "worse" (in the "worse is better" sense) becomes entrenched, and then "better" never gets a foothold. This has been the consistent pattern throughout computing history, and I think this is why some of us invest the energy in promoting "better" from the outset. It's just too costly to go back and revisit certain classes of decisions, especially architectural decisions, once a system is deployed.
In fact, this thinking is the primary reason that I do any recreational programming, and that my recreational programming tends not to be in C, C++, or Java. That's what I use for work (i.e. worse is better). At home, I have the luxury of using "better."
But I am interested in hearing counter-points, or places where I may be oversimplifying.
No, I think you get it, and quite reasonably say that it's not worth going to war over. I've essentially arrived at the same conclusion, but I feel the need to put a verbal stake in the ground and say that choosing RPC over REST is choosing worse over better, and that such decisions will not be revisited, so be very careful about the areas that are hardest to predict, such as scalability, cachability, and the like, before making large deployments based on an RPC architecture. That's all.
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. [iRights]
It's never a bad thing to say "this is my understanding right now; what do you think?" You'll either get confirmation, as you have, or correction. Both are valuable, as you obviously know.
And I need to thank you for taking my posts in precisely the spirit that they were intended, and opening the dialog. I greatly appreciate that!
9:02:53 AM
