REST: Representational State Transfer

Another tech entry for my future reference (and those that are IT inclined):


The World Wide Web contains a great example of the software architecture style known as REST. Using the WWW, messages can be communicated via the HyperText Transfer Protocol (HTTP). http://dramse01.blogspot.com/ is known as a Universal Resource Identifier (URI). With the REST architecture, it is important that each entity receive its own unique URI. For example, each blog entry would be considered an entity, and therefore, should be given a unique URI.

As with any software, the ability to create, select, update, and delete information is an invaluable (and typically required) function. This holds true regardless of how the information is stored: in memory, files, databases, etc. The REST architecture equivalent of these most widely needed functions are in the form of the following HTTP methods: POST, GET, PUT, DELETE.

The biggest difference I see in a RESTful application is the abundant use of URIs - which points to not only the location of the application, but to also the specific entity in question. Then with a RESTful application, you rely on four key HTTP methods and supporting criteria. Whereas in other web applications (e.g., Remote Procedure Call (RPC) based apps), there is an emphasis on building out all of the possible actions, passing in the location and which entity requires interaction as part of the command input.

While I'm not sure I entirely understand all the pros and cons of REST yet (as probably indicated in my brief write-up), I'm reviewing GData - Google's Data API - and the REST architecture seems more intuitive as I continue to read.