Here I am, a Busy Developer trying to work his way up to being a real Computer Scientist. In doing this, I subject myself to things like RPC vs REST. I see apparently intelligent people vehemently disagreeing about something, I figure there's something to it. This may be naive. I hope that by hurting my brain with this noise, I might take some of the hunch out of my back that gets me just one more caveman level up the evolutionary chart. I hope you all don't mind hearing my grunts and unks.

Dave linked to me with an Oy. Was that from my quoting of a quoter quoting? Or is that an Oy on this REST thing getting all outta hand? :)

Well, here it goes again: I found Gordon Weakleim linking to me from my referrers (yay for referrers!), where quotes someone on a discussion forum as having said "REST, I'm afraid, is unlikely to get anywhere until it is presented in a more utilitarian fashion. It feels much too much like a philosophy or religion or something." And I agree with this, too. I got introduced to XML-RPC via simple toolkits and real problems solved with satisfaction, and I'm learning SOAP slowly the same way. Gordon also captures some of my other sentiments.

I think I get REST now. Maybe. Between my last post on REST and finally finding and reading Paul Prescod's "REST and the Real World", I feel somewhat illuminated.

I also feel very, very behind. This has all probably been covered ad nauseum on mailing lists I haven't read yet, but this is what I thought on Paul's article:

Using someone else's [RESTful] web service requires you to understand their data structures (XML vocabulary and links between documents). . . . RPC APIs merely hide the problem behind an extra layer of non-standardization. First you must figure out the method names available. Then you must still figure out the data structures that may be used as parameters. And then behind those data structures is the implicit data model of the web service.

Hmm. Yes, in an RPC API I have to supply my customer with my method definitions-- including their names, parameters, and return values. This seems directly comparable to supplying my customer with all the URIs exposed by my app's resources, as well as the data structures used by them.

How are these cases so very different?

There is no free lunch. The biggest problem most will have with REST is that it requires you to rethink your problem in terms of manipulations of addressable resources instead of method calls to a component.

I don't want to rethink my problem, at least not without a clear payback. When I first learned to rethink my problems in object oriented programming, I got immense payback. I haven't seen the clear payback case for REST yet. So far, it looks like an interesting abstraction with a lot of vagueries, name calling, and intimations of harm and danger.

Of course you may actually implement it on the server side however you want. But the API you communicate to your clients should be in terms of HTTP manipulations on XML documents addressed by URIs, not in terms of method calls with parameters.

My customer doesn't want to mess with this, and doesn't want to learn about it.

Your customers may well prefer a component-based interface to a REST interface.

Yup, they do. My chances of altering their behavior is slim to none-- at least not without a clear case of payback to present.

Programmers are more used to APIs and APIs are better integrated into existing programming languages. For client-side programmers, REST is somewhat of a departure although for server-side programmers it is not much different than what they have been doing for the last several years, building web sites.

The server-side programmers I work with have been building CGIs and various server-side things which treat URI's as mere gateways onto their applications. REST is pretty different than what they've been doing for the last several years.

REST is about imposing a programming discipline of many URIs and few methods. RPC allows you to structure your application however it feels best to you. Let it all hang out! If a particular problem can be solved with RPC, and future extensibility and security are not going to be issues for you, you should certainly use the looser approach.

I still don't see the payoff of few methods with many resources versus many methods with few resources. Either way, should I change my application in the future I'll need to supply my customer with new data descriptions, or with new method descriptions. How does REST make me magically extensible? Am I not seeing something?

The security angle I can sort of see, given the already built-in ability of web servers and firewalls to control HTTP methods and URI accesses. But, most times I want my application to manage its security and access control, not the web server or firewall. Maybe this is a flaw in my application.

Anyway, the simplicity of REST feels like a possible elegance to me, which I like. Elegance feels warm and fuzzy, not itchy. XML-RPC is obviously a bit of a workable hack. Being able to RESTfully reduce my app down to database-like access via a web of URI resources seems neat. But, the whole REST thing feels like an inside-out turn of many things. This is not useful to me unless I can find some abstraction or toolkit to help me wire my apps up to things in the REST way. XML-RPC was quick for me to get hooked on, since it was a mostly drop-in solution with me writing only a few wrapper methods.

Now that I understand REST better, I see that I could possibly do most of what I do with SOAP and XML-RPC in a RESTful manner with a bit of brain bending. It reminds me of threaded versus async / event driven programming. But I don't know why I should bother: I'm still looking for the payback of REST and I'm still looking for the danger inherent in the RPC model.

shortname=oooabh