(5) Fri Nov 03 2006 17:31REST Web Services:
I'm writing a new book and it's called REST Web Services. It will be
be the only book of its kind, and everyone should buy it who writes
computer programs that work over the web.

There are lots of books about Big Web Services: complex
distributed-object systems that reproduce the mechanics of method
calls over HTTP. The problem is 1) these systems are way too big for
what they do, and 2) they're on the web but they aren't of the web. They don't use any
of the web's features, or interact with anything else on the web. They
just use HTTP as a transport protocol. They could just as easily run
over TCP and get better performance.

These un-weblike systems were able to take the name "Web Services"
away from the competition because the competition is... the web. Just
writing programs that interact with the web. Sounds pretty sketchy! The web may be all
right as a platform for serving movies, or selling books, or trading
stocks, or democratizing publishing, or coordinating huge volunteer
projects, or searching much of the information currently in existence,
but there's no way it's up to the task of managing Accounts Payable!
For that you need... Web Services!

As Big Web Services gathered steam, the pro-web forces rallied
behind the banner of REST: a name for the design philosophy that made
the human-visible web so successful. They preached simplicity,
addressability, statelessness and the uniform interface of HTTP. They
also got into lots of heated arguments about what REST really meant.

Some organizations created services that claimed to be RESTful, and
others critiqued those services and said they weren't RESTful really,
and is "RESTful" even a word? Meanwhile the world's programmers
started finding options in their IDEs that generated code for Big Web
Service clients and servers, so they wouldn't have to do so much
programming.

I got the idea for a REST book when I started seriously trying to
figure out what was and wasn't REST. I noticed that though certain
best practices showed up repeatedly in REST folklore, they never
really progressed beyond that point. I decided to write a book that would set down
the folklore and hopefully create some new canon, some common ground. I got Sam Ruby to agree to do
the hard parts. And when I started work on the book I discovered a
basic rule of thumb, a framing device that really focuses on what's
important about REST, and makes it easy to tell what's RESTful and
what's not.

We call this framing device the Resource-Oriented Architecture (we're
not the first, but the other uses are compatible with ours), and
I'm going to be writing about it a lot more in NYCB. It's too
good to keep hidden in a book along with a bunch of implementation
details.

Some people might say, "Leonard, why are you guys even writing this
book? There already are lots of books about the web, and REST is just
the web, right? That's the whole point! We wrote those books back in
the 90s."

To them I say: "Some people, think about Ajax for a bit. Ajax, as a
technology, is only about two years old, but it's composed entirely of
technologies that are much older, like Javascript and
XMLHttpRequest and the browser DOM. So why are there all
these books about Ajax? (Including Christian Gross's Ajax and REST Recipes, coming out later this month and seemingly the only other book to mention
REST in the title.) Why does Ajax excite people when DHTML was a big
yawn? Because Ajax is a way of framing these old technologies so that
people can do awesome things.

"There's nothing on the market that explains what REST really means and how to make it work for
you. Nothing about programming the web in a way that's more structured than screen-scraping without falling into the pit of Big Web Services. This is a way of framing preexisting technologies
that lets people do awesome things."

Then I add, "Speaking of Ajax, did you know that an Ajax
application is basically a REST web service client that runs in your
web browser? That's why Christian Gross's book is called what it is,
and that's just one of the amazing reality-twisting facts you'll learn
from my new book, Jon." Because I'm talking to Jon Stewart! I'm on
The Daily Show, plugging my new REST book! It's a dream come
true! But wait--I'm not actually on The Daily Show! I'm just on
a clip from The Daily Show that someone uploaded to YouTube!
And now someone is sending a DELETE request to my URI! I can see the
Authorization request header, its value is "DMCA Takedown
Notice", and nooooooooooo

Then I wake up. Whew! It was just a regular dream, not a dream come true. I get up and go back to
work on my REST book.

Ruby is awesome and the Ruby Cookbook was a lot of fun to write,
but it wasn't my idea. It's part of a high-profile O'Reilly
series. There was destined to be a Ruby Cookbook, written by
somebody, from the moment Rails strapped an E motor to Ruby and
hit the igniter. This book was my idea, and Sam and I are driving
it. In the coming months I'll be writing a lot more on this
topic. There's a lot of work we need to do in the real world, in
addition to writing stuff down in a book.

PS: I say this on the homepage for the book, but in case you haven't clicked through and you're interested in REST, please email me or Sam. We'd love to have you help us with the folklore and best practices, and we need lots of reviewers.

One comment on the current outline - there's "Representation formats", but what of the underlying models of the information the formats represent? In a similar vein, it's good to see the microformats reference, but it would also be nice to see such a section covering semweb tech - in particular the SPARQL Query Language and RDF Protocol, very much in scope I'd say.

(The stuff usually called Semantic Web Services is a bit of a nightmare at this point in time - ironically probably closer to WS-* than REST. But there's some great potential in using RDF as a means to merging data from disparate sources).

Danny, matching data formats to an information model is a great idea. I just read TBL's web-popularization book as research into the web's history and it got me really interested in the Semantic Web ideas.

Previously I had mainly dismissed it as somewhat crackpot stuff that was trying to take everything over de novo. But TBL explained it in a way that made me see things like REST web services, microformats, and even del.icio.us's tagging as approaches towards the Semantic Web. So I'm definitely going to start working more of that stuff into the outline.