Sunday, January 22, 2012

REST - Taking a Closer Look (Part 2)

First goal is understanding the request model as stated in my previous post REST - Taking a Closer Look (Part 1).  For this portion of the exercise, I will start take a closer look at the Book implementation.

The book model is simple concept and one that we would recognize from our daily lives.  A book has basic properties,
  • title
  • description
  • author
  • ISBN
What is REST?  REST is representational state transfer (see Wikipedia for more details).  More or less, it's a software architecture by which we transfer state from one place to another.  In terms of the web, transferring state of resources from the client (browser) to the server (web server->database).  I strongly suggest reading the Wikipedia entry, as it has some very useful and important details on implementation and separation of concerns.

REST sets out to model the concept of CRUD operations (Create, Read, Update, Delete).  It mimics these operations by using POST to Create, GET to Read, PUT to Update, DELETE to, well, Delete. 

With a simple understanding of REST, let's look a little closer at a Book implementation.  Initially, you'll want to see a list of books that are available.  We would model a URL using the guidance of REST like this.
GET http://localhost:8080/research-grails-rest/book/list
This URL has no unique pieces to it.  The resource is defined by book and the operation is defined by list. As a result, all defined knowledge of the representation of a book will be listed.  We can say this about any resource that is available in the system that provides an authorized list operation.  Within the context of the Grails application, all of the work is done on the server and returned in an HTML page.  However, in an Ajax based client, the list operation would return all of the data as a data structure and decouple the operation from the client view.

Screenshot: Result of book/list.

As a part of the architecture, the GET request could be marked as cacheable.  In other words, the browser could use a copy of this data from it's local cache rather than making a request to the server.  The resource, book, would have to mark the list operation as cacheable and provide a timeframe in which that cached data is considered fresh.  Once that cache entry is considered stale by the browser or by revalidation by the server, a new version of the resource will be made available to the end user.

For a simple operation like, GET, this about the extent of it.  In the next post, I will discuss the POST method (Create).

No comments:

Post a Comment