RESTful Web Services Cookbook

Save 60% on Jan 19, 2011

2011-01-18T22:33:43Z

Here is the scoop I just received from O’Reilly.

Save 60% – Top 25 of 2010

Best of Ebook Deal of the Day – http://post.oreilly.com/rd/9z1ztpijtp7meklse9bq1u34nnvf1fdmc1n0battp2g

For one day only, you can save 60% on our best of “Ebook Deal of the Day” titles – the top 25 of 2010. Ebooks from oreilly.com are DRM-free. You get free lifetime access, multiple file formats, and free updates. One day only. Use discount code DDT25 in the shopping cart.

Now Available in Stores

2010-03-11T18:32:43Z

This book is now available in stores.

Many thanks to Mark Nottingham, Eben Hewitt, Colin Jack, Stefan Tilkov, Norbert Lindenberg, Chris Westin, Dan Theurer, Shaunak Kashyap, Larry Cable, Alan Dean, Surya Suravarapu, Jim D’Ambrosia, Randolph Kahle, Dhananjay Nene and Brian Sletten for their valuable and critical feedback on this book.

If you are interested reviewing the book, please email me directly. The Yahoo! Developer Network may be interested in publishing a review.

Rough Cuts Back Online

2009-12-22T16:55:46Z

A few days ago, several people noticed that the link to the rough cuts draft was returning a 404. The book title was also missing from the search index on Safari. Both are now working correctly.

Here is the link from Safari – http://my.safaribooksonline.com/9780596809140.

Pre-Production Draft Now on Safari

2009-12-21T02:43:51Z

A pre-production version of the RESTful Web Services Cookbook in now on Safari Online (requires login to your Safari account). This draft now contains 106 recipes in 14 chapters including a new chapter on security.

Currently, the link at Safari Online – http://my.safaribooksonline.com/9780596809140 requires login. Without login, it returns a 404.

Second Draft on Rough Cuts

2009-11-19T15:18:34Z

A second draft of the book is now available on Safari Online. This revision includes numerous polite comments from reviewers. In the last two months, I have received very valuable feedback on the content, tempo and accuracy of the recipes in the book. I can’t thank the reviewers enough.

Rough Cuts Now Available

2009-09-05T07:53:37Z

A rough cuts version of this book is now available via Safari Online. See http://my.safaribooksonline.com/9780596809140. This is the first full draft of the book. Although the outline is more or less final, there are number of recipes that need to be refactored and rewritten. Your comments are very much appreciated.

Updated TOC

2009-08-13T14:26:34Z

Just updated the Table of Contents for the first half of the book.

A Measure

2009-07-09T15:38:26Z

As we work through various aspects of designing and developing RESTful applications and documenting recipes in our RESTful Web Services Cookbook, we realized the need for a way to measure the quality of guidance that this book provides.

There are several ways to come up with a measure. We could use Roy’s definition of REST in its purest form as the measure. Or, we could rely on web standards such as HTTP, URI, Atom, AtomPub, HTML, XML, RDF etc, and advocate a standards-driven approach for RESTful applications. Alternatively we could look through the lens of software infrastructure such as web servers, proxies, caches, programming libraries etc. as well as ease of programming, and general principles of building distributed systems. Another possibility is to use a combination of all of the above, applied on a case by case basis.

Until recently, we were using the last approach – a combination of all of the above. But we could not put it to use consistently. It didn’t always help us decide between options. As we were mulling through different angles – going through multiple rounds of edits, writes, and rewrites, it became apparent that we needed a much simpler measure that can tell us quickly, and unambiguously, whether any given recipe is worth including in this book. Finally, we came up with this simple yardstick.

Can we, with a straight face, explain and justify any given recipe in this book to our prospective readers? If the answer is yes, the recipe stays. If not, it’s out.

Why did we settle on this non-technical yardstick? Because, of all the material out there on REST, there is a non-trivial amount of literature that neither of us can justify with a straight face in an informal setting. There are several recommendations that, on paper, look fine but in real-life, don’t make much sense. There are standards and practices that are technically correct, but cause more work or introduce headaches, and hurdles to success.

P.S. We still have nearly 30% of the first draft pending. Once we finish up the first draft, we plan to spend more time on this blog. Thanks for your feedback so far.

URI Parameters for Resource Naming

2009-06-01T15:13:32Z

Here is an example that we are trying to grapple with. Say, a server is providing two URIs.


http://www.example.org/some-resource

http://www.example.org/soma-resource;select=a,b,c

Of these, the purpose of the second URI is to refer to a portion of the resource identified by the first URI. The server could use query parameters or matrix parameters. That is just an implementation detail. Let us assume that these URIs are opaque to the client and the server is using links to convey them to clients.

This usage is fairly common with GETs. However, most in the REST community (us included) discourage such URIs with PUT and DELETE. Why so?

Here is another example that may influence your answer.


http://www.example.org/user/1234

http://www.example.org/user/1234;select=firstname

When it is okay for a client to GET the first name via the second URI, why is it considered bad to allow it to update the first name resource by using the same URI?

Would you prefer changing the above URIs to the following?


http://www.example.org/user/1234

http://www.example.org/user/1234/firstname

If so, why?

Thanks in advance for sharing your views.

Caching Read-Write Web Services

2009-05-23T03:51:38Z

We’re mapping out the chapter on caching; lots of discussions back and forth. We both think this will be an important part of the book.

So far, here are some key topics we plan to cover:

Validation Caching for Dynamic Resources (ETags, Last-Modified-Date. etc)
Expiration Caching for Static Resources (Expires, Max-Age, etc.)
Caching Composite Resources (Can you? Should you?)
Keeping Resource Caches Fresh (Using Vary, Location, and other Cache-control elements to keep intermediaries up-to-date)
Cache Invalidation and Back-end Data Stores (When the data store gets updated, how does the web cache get back in sync?)
Client Caching Techniques (If you’re writing an HTTP client, you need to support browser-like caching)

Are these the right things to cover? Are there others we missed?