An interesting article found by googling jvmpi jit http://www.google.com/search?q=jvmpi+jit&btnG=Google+Search&hl=en&lr=&ie=ISO-8859-1&safe=off

10:08:21 PM  #  

At my company we are using a REST-based interface to allow the import and export of data to and from our trading system. We considered using SOAP, but felt that it would create an unnecessary extra layer of complexity without offering any benefits over a REST architecture. In fact SOAP's RPC approach seems to have many short comings versus the Representational State Transfer approach

I do need to think hard about this issue. My less than adequete understanding of REST doesn't make me very enthusiastic about it though. All it says is you "pull" data from server to client; then you do what you want with the data; then push some bits out. Like the web. REST proponents think this is all grand... Apparently when designing systems in REST way, URIs need to be chosen very carefully as they are the only interface to the system. Semantics of actions are blurred with URI and HTTP GET/POST.

Problem I have is that REST sounds too much like untyped (or single type = text, ugh), untype-able, unsafe smashing of bits a la pipes. Server and client do not actually carry conversation and negotiation but they repeat memorized dialogs - they have to know exact context of data they are passing to and fro to have meaningful interaction. But data in this case can be arbitrarily sliced and diced at either end. Bring on more parties, complexity goes up pretty fast.

But still I find REST intriguing. It's very possible I have made some fundamental mistakes somewhere in my course of studying REST.... I do agree for simple things, REST is simpler than SOAP. It shouldn't be too difficult then to put RESTy interface on top of SOAP either.

Problems to think about:

• annoymous URIs -- is such a thing possible??
• cost of naming -- just like in using variables in programming or keeping lots of files, creating and maintaining names are a costly business.
• semantic overloading of verbs -- is this sound?
• general principles surrounding protocols vs APIs
• security of REST -- many names are kept secret for very good reasons
• lots more...