Always with deliberate irony, but my infernokrusher prose on the REST book page has two other goals. First, to market the book, to make people excited about it so I can ask them for help. Second, to act as a guideline and a goal. As the book nears completion I will find myself wrestling with the question of whether the manuscript does or does not put the "web" back into "web services". If it doesn't then we should probably do some more work on it. Does it drive all opposition before it, or is it just okay? Etc.
I'm exhausted, so no continuation of the taxonomy series tonight. But I would like to give an update on the name of the book. I got about 20 emails about it, almost uniformly against "with Ruby" in the title. On a semirelated note I can report that "with Ruby" is almost certainly gone from the title. The title is not finalized; editor Michael thinks "REST Web Services" is ungrammatical. But I think we agree on what kind of name will capture the goal of the book: an introduction to REST that has contains real examples but also has some philosophical heft to it.
The best argument for "with Ruby", I think, apart from "cheap trick to sell more books", is the same argument for using Ruby as our implementation language. We're not using Ruby because its XML support or HTTP client library is the best (it's not), but because Ruby is where the open source REST work is happening. This gives us lots to talk about without having to be polyglot throughout the whole book. Right now you don't see things like ActiveResource happening in other languages. (Note: this statement is precisely calculated to bring people out of the woodwork saying "you've neglected my awesome non-Ruby server-side REST tool!" so that I can take a look at said tools.)
The counterargument is that most peoples' interest in REST doesn't start on the server side. It starts when they write clients for big-company services like Yahoo!'s and Amazon's and Google's. They hear the term "REST" used (possibly incorrectly), and want to know more about the underlying architecture. There will always be more clients than servers, and the client programmers are using all kinds of languages.
Those whose interest does come from the server side are either trying to decide what to use, or just curious about RESt. Inside the book it's fine to say "Like REST? Your best bet right now is Ruby." But the book will fly past a chunk of its audience if the title says: "Like REST and Ruby? You'll like this book."
(3) Wed Nov 08 2006 18:10 Book Name:
"Leonard is may be overly-self-congratulatory (perhaps with deliberate
irony), but it sounds like there is a lot of demand for such a
thing."
- Comments:
Posted by Susie at Wed Nov 08 2006 18:59
You've neglected my awesome non-Ruby server-side REST tool! Oh wait..
Posted by Mark Baker at Thu Nov 09 2006 00:25
"Ruby is where the open source REST work is happening" ... for a very narrow definition of "REST", I suppose.Rails 1.0 was a real mess from a REST POV. The new REST-motivated stuff is interesting and a great improvement, but there's a *lot* more going on on the Web, and under the banner of REST, than just Web app frameworks.Personally, I'd expect a REST book with code samples to use multiple programming languages.
Posted by Leonard at Thu Nov 09 2006 00:29
Hey, you're supposed to give examples so I can look at them. :) What are you thinking of? The main thing I know about is RESTlets.The client chapter does use multiple programming languages. When covering a language-specific topic (like Ajax or ActiveResource) we use the appropriate programming language. The default is Ruby.