I’ve been learning and thinking a lot about REST (Representational State Transfer) and how it stacks up to RPC-based technologies like SOAP and XML-RPC. The idea behind REST is that the Web already has everything it needs to power XML-based, transactional Web services — HTTP-native actions such as GET, POST, PUT, DELETE, etc. applied to a “potentially infinite set of nouns (URIs).”

The REST view is very seductive in its simplicity. In fact, most RPC operations can be mapped to REST equivalents. From the RESTWiki:


- when retrieving information without changing the state at the server, use GET

- when explicitly setting some piece of state on the server, use PUT
- for pretty much everything else that changes state at the server in a loosely coupled way, use POST
- for other operations that change state on the server in an early-bound manner (i.e. the client needs to know explicitly what is happening), define a new HTTP method.


What about structs and complex datatypes? REST doesn’t require a schema, so you use any one you wish. Things get a bit tricky when you get into things like discovery of services and methods, because at some point you need to know how to find and get at a Web service’s inner workings. As a developer, probably the most obvious benefit I see is you don’t need much to get started, no crazy tools, no SOAP::Client, etc. All you need is something that can handle HTTP and parse an XML payload. In other words, you need less glue.

More on this later, as I learn.

Previously: Mozilla 1.0 Release Candidate 1

Next: Layne Staley