Nathan CrauseMusings of a Software Developer

It seems all the rage lately to offer services using the "RESTful" design. I've tried it, and don't like it. Here's my reasons:

1. It's too linked to HTTP - while HTTP is the current accepted standard as transport layer, tying in your systems so intrinsically to it removes any possibility of using some other transport protocol. Let's use the stock market as an example. These are extremely high-volume systems - using HTTP as a transport layer would be crippling and slow. This is why most of these systems I've worked with tend to use proprietary data structures transported over TCP/IP. Same goes for banking - ever noticed how no banks offer high-volume EFT/ACH functionality over HTTP?
2. It doesn't handle complex data well - the whole point of REST is to jam as much info into the URL itself as possible. This whole idea crumbles when your data becomes complex (for example, street addresses). The only solution I've seen for this (as is done by ActiveResource, as an example), is to revert back to using HTTP request parameters. This links closely then to #3 ...
3. Lack of consistency - as we can see in #2, complex data sets immediately cause you to deviate from the RESTful paradigm. However, this issue goes even deeper. What about the resulting data? REST defines no standard format for the results, which means there can never be any single way of processing for RESTful web services. This is probably why each language/framework seems to have their own way of handling this - most of which are completely incompatible with each other. You ultimately end up having to implement a way of processing the results for every web service.
4. No type-safety - this might not be a big issue for those working in dynamic-type languages such as JavaScript, Ruby, Groovy, etc., but it comes a really huge problem when working with static-type languages such as C/C++, Java, etc. The paradigm itself provides no means of limiting the data which may be sent/received.

For simple remote call, a better option might be JSON-RPC; it handles most of the deficiencies with REST, but is also typeless (point #4).

When looking at other solutions, let's be honest, SOAP is a great-big bloated mess. It's simply too complex for the small benefit you gain. The SOAP folks have tried to fix this by the introduction of WSDL, but some implementors (cough, cough, Microsoft) end up generating WSDLs which won't parse under other languages (often times even violating basic XML convensions).

All in all, I tend to favour XML-RPC. It's simple, it's well defined, and it suffers from none of the deficiencies of REST and removes the over-complexity of SOAP.