Features of the Resource-Oriented Architecture
(Page 1 of 4 )
In this second part of a four-part series on Representational State Transfer (REST), you will learn about two of the most important features of the Resource-Oriented Architecture (ROA). This article is excerpted from chapter four of the book
RESTful Web Services, written by Leonard Richardson and Sam Ruby (O'Reilly, 2008; ISBN: 0596529260). Copyright © 2008 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.
Addressability
Now that I’ve introduced resources and their URIs, I can go in depth into two of the features of the ROA: addressability and statelessness.
An application is addressable if it exposes the interesting aspects of its data set as resources. Since resources are exposed through URIs, an addressable application exposes a URI for every piece of information it might conceivably serve. This is usually an infinite number of URIs.
From the end-user perspective, addressability is the most important aspect of any web site or application. Users are clever, and they’ll overlook or work around almost any deficiency if the data is interesting enough, but it’s very difficult to work around a lack of addressability.
Consider a real URI that names a resource in the genre “directory of resources about jellyfish”: http://www.google.com/search?q=jellyfish. That jellyfish search is just as much a real URI as http://www.google.com. If HTTP wasn’t addressable, or if the Google search engine wasn’t an addressable web application, I wouldn’t be able to publish that URI in a book. I’d have to tell you: “Open a web connection to google.com, type ‘jellyfish’ in the search box, and click the ‘Google Search’ button.”
This isn’t an academic worry. Until the mid-1990s, when ftp:// URIs became popular for describing files on FTP sites, people had to write things like: “Start an anonymous FTP session on ftp.example.com. Then change to directory pub/files/ and download file file.txt.” URIs made FTP as addressable as HTTP. Now people just write: “Download ftp:// ftp.example.com/pub/files/file.txt.” The steps are the same, but now they can be carried out by machine.
But HTTP and Google are both addressable, so I can print that URI in a book. You can read it and type it in. When you do, you end up where I was when I went through the Google web application.
You can then bookmark that page and come back to it later. You can link to it on a web page of your own. You can email the URI to someone else. If HTTP wasn’t addressable, you’d have to download the whole page and send the HTML file as an attachment.
To save bandwidth, you can set up an HTTP proxy cache on your local network. The first time someone requests http://www.google.com/search?q=jellyfish, the cache will save a local copy of the document. The next time someone hits that URI, the cache might serve the saved copy instead of downloading it again. These things are possible only if every page has a unique identifying string: an address.
It’s even possible to chain URIs: to use one URI as input to another one. You can use an external web service to validate a page’s HTML, or to translate its text into another language. These web services expect a URI as input. If HTTP wasn’t addressable, you’d have no way of telling them which resource you wanted them to operate on.
Amazon’s S3 service is addressable because every bucket and every object has its own URI, as does the bucket list. Buckets and objects that don’t exist yet aren’t yet resources, but they too have their own URIs: you can create a resource by sending a PUT request to its URI.
The filesystem on your home computer is another addressable system. Command-line applications can take a path to a file and do strange things to it. The cells in a spreadsheet are also addressable; you can plug the name of a cell into a formula, and the formula will use whatever value is currently in that cell. URIs are the file paths and cell addresses of the Web.
Addressability is one of the best things about web applications. It makes it easy for clients to use web sites in ways the original designers never imagined. Following this one rule gives you and your users many of the benefits of REST. This is why REST-RPC services are so common: they combine addressability with the procedure-call programming model. It’s why I gave resources top billing in the name of the Resource-Oriented Architecture: because resources are the kind of thing that’s addressable.
This seems natural, the way the Web should work. Unfortunately, many web applications don’t work this way. This is especially true of Ajax applications. As I show in Chapter 11, most Ajax applications are just clients for RESTful or hybrid web services.But when you use these clients as though they are web sites, you notice that they don’t feel like web sites.
No need to pick on the little guys; let’s continue our tour of the Google properties by considering the Gmail online email service. From the end-user perspective, there is only one Gmail URI: https://mail.google.com/. Whatever you do, whatever pieces of information you retrieve from or upload to Gmail, you’ll never see a different URI. The resource “email messages about jellyfish” isn’t addressable, the way Google’s “web pages about jellyfish” is.‡ Yet behind the scenes, as I show in Chapter 11, is a web site that is addressable. The list of email messages about jellyfish does have a URI: it’s https://mail.google.com/mail/?q=jellyfish&search=query&view=tl. The problem is, you’re not the consumer of that web site. The web site is really a web service, and the real consumer is a JavaScript program running inside your web browser.§ The Gmail web service is addressable, but the Gmail web application that uses it is not.
Next: Statelessness >>
More Web Services Articles
More By O'Reilly Media
|
 This article is excerpted from chapter four of the book RESTful Web Services, written by Leonard Richardson and Sam Ruby (O'Reilly, 2008; ISBN: 0596529260). Check it out today at your favorite bookstore. Buy this book now.
|
|
