Book review: RESTful Web Services

You know your next Web application would benefit from a Web API, but you can't justify it to Management. Here's how to do it anyway

By Don Marti, LinuxWorld.com, 07/09/07

 Start a discussion    Print article

 Comments (1)    Print article

Without an occasional flash of subversive literature, corporate inertia and the superior political skills of the world's idea-squashers would have turned the world of networks and computers into a gray, authoritarian wasteland long ago.

Related links

Top ten Web APIs you can really use

Story tools

Sponsored by:

E-Mail article
Print article
Contact author
AIM article	del.icio.us
Reddit	Digg
Stumble	Slashdot It!

Fortunately, we have books such as Lincoln Stein's How to Set Up and Maintain a World Wide Web Site and Running Linux by Matt Welsh and Lar Kaufman. The power of subversive books is that they let you create some useful functionality without a budget or the conventional IT politics that go with getting the budget. Put a Web site on an underused server, or a Linux install on a discarded PC.

The new great subversive computer book is here. The benefit of RESTful Web Services, by Leonard Richardson and Sam Ruby (O'Reilly and Associates, 2007) and the Representational State Transfer (REST) philosophy in general, is that REST lets you sneak a big idea, a Web API, into an existing Web project. No heavyweight libraries, nothing to call attention to yourself. "No, sir, we aren't splashing out on any of those big scary Web services here. Just finishing the Web project as ordered."

What makes REST so easy to incorporate into an already-approved Web project is that it is mostly the emergent result of several decisions that you can logically say are the right ones for your site anyway.

The rules of REST are easy to justify as part of a conventional Web project. Use URLs with logical paths to refer to different items. Don't just POST everything to one place. Use GET and POST correctly. Don't POST a search, or do a GET for an action that has consequences.

Make your application produce the correct HTTP status codes: 200 for OK, 201 if you create a new resource, 300-something for different flavors of redirect, and 404 for a 404. Read the section on HTTP status codes very carefully. Getting these right is a big win for doing test-driven development, and simple clients such as link checkers. (If you write a Web application  to report your hamster's weight, and the hamster escapes, should you return a 404?)

Featured White Papers

• Hey, Can I Borrow Your Keys? I'd Like to Trash the Kingdom