
Give it a REST
March 21, 2008Brian Sletten gave a nice talk at Tuesday’s CJUG meeting on REST. He focused on the principles behind resource-oriented architectures rather than implementation of RESTful services, although he did go over a few examples of such services.
Some points that I took note of:
- With the uniform addressing model provided by REST, business models can be mapped to information technology systems without having the mapping be dependent on the technology
- The addressing model makes it easy to pass a reference to a resource to another system, rather than a copy the resource data
- REST consists of unlimited nouns(names/URLs of resources), limited verbs (GET, PUT, POST, DELETE), and content types (text/html, image/jpeg, etc)
- The limited set of actions/verbs means that clients use uniform interaction model for all resources
- Because GET is intended to be idempotent, any resource can be cached at an intermediate point between the client and server without knowing anything about the resource itself other than it’s URL. In contrast, data returned from a SOAP service can not be cached without the cache having specific knowledge about the service operations.
- Service description should be different depending on whether it’s being described to a person or to software. When describing to people, a partial URL can return HTML documentation as well as complete URLs which provide a user interface to resources. When describing to software, resource attributes can be used to request a resource’s format definition, such as an XSD schema.
- URI structure can be designed to be stable over time by using the attributes of the resource that naturally fit into a hierarchy as part of the URI path. Attributes that don’t fit into a hierarchy can be included as querystring parameters.