The thing I really liked about this article was the low-barrier-to-entry approach Stefan took. For example, instead of starting out with why things are called "resources", he simply says "give every thing an id". I can see this resonating with developers new to REST because words like resource are quite overloaded. Another thing that takes some getting used to is the fact you can also model processes as a resource:
Taking the idea of identifying everything that is worth being identified further leads to the creation of resources that you usually don’t see in a typical application design: A process or process step, a sale, a negotiation, a request for a quote — these are all examples of “things” that merit identification.
Stefan also covers several other fundamental REST ideas:
- Using links to traverse the web of relationships between things.
- The fact that there is a standard set of operations (GET, PUT, POST, DELETE, HEAD, OPTIONS), each with formal semantics, that are sufficient to express your (web) services and can be used by ubiquitous clients such as browsers or curl.
- Using content negotiation to ask for different representations of things (e.g. JSON v's XML).
- Communicating statelessly so that the system is more robust and easier to scale.
There is also a nice summary of the theory behind REST. I started getting into REST a few years back when Paul Prescod was educating the great unwashed on xml-dev. This is the best introductory article on REST I've seen so far, so I highly recommend taking a look if you are at all interested in this emerging architectural style.