No REST for the wicked or the Corporate Developer

REST vs. Other Web Services

I know this topic has probably been covered a million times in the last couple years, but being a developer in a large corporate where "standards" are imposed to limit the craziness that would ensue without them. I have actually only now started to have a look at it. The reason for me looking at it now is the Spring 3 RESTful support, which I plan to play with in the next day or so.

Not really going to go into SOAP and XML-RPC, as I generally know that and they are the only type of webservices we implemented in my working environment. I know that SOAP and XML-RPC, uses an envelope, XML and is well defined / strongly typed... bla bla bla...

So from random sources this is what I found about REST:

REST stands for Representational State Transfer
Each unique URL is a representation of some object.
You can get the contents of that object using an HTTP GET.
You may use a POST, PUT, or DELETE to modify the object.
It is not necessary to use XML as a data format, so for small amounts of data it can be significantly lighter on bandwidth.
REST as a protocol does not define any form of message envelope.
REST takes advantage of HTTP caches. (A cache can't to do anything a POST; but they can cache GETs and expire those entries based on PUTs and DELETEs.).

So where to use RESTful ?
Well from what I just read, it is a smaller, quicker, HTTP interface which sounds perfect for replacing all "system internal" service calls happening between components where direct RPC is not ideal and it really isn't worth the time, effort and red tape to set up a WSDL / XSD.
(that was a really long sentence)


Ignore: just for proof of ownership: GUNCP4EUNAGF