(3) Wed Nov 01 2006 15:50 Involuntary NaNoWriMo:
Several people I know are doing NaNoWriMo, including some of Sumana's coworkers. Sumana was tempted to do it but I told her she has too much else she has to do. I'm tempted to do it as well, but I already have a book deadline at the end of the month. So it's like I'm doing it already but not getting credit.
Thu Nov 02 2006 22:40 Milestones Around My Neck:
As of today my book is 150 pages long (public announcement coming soon, honestly, along with lots of me complaining about how things should be other than they are; which, though cranky, will provide interesting content on this weblog). Also, I finished my story today, and it did in fact turn into a novella. Now working on it with Brendan; it's called "Vanilla".
(1) Fri Nov 03 2006 08:51 Disturbing Slash Concepts:
CJ from Reginald Perrin and CJ from The West Wing.
(5) Fri Nov 03 2006 17:31 REST 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
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
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
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
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
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.
Sat Nov 04 2006 19:36 Daylight Come And It Won't Go Home:
I probably shouldn't have announced my book project on a Friday afternoon. In my defense, yesterday I thought it was Wednesday. But the book gotten a huge reception to the point that I can only hope we can meet everyone's expectations. A huge number of smart people want to review the book so I feel pretty good about it.
Let me talk about light pollution. Recently I moved to a place where I have around 18 million neighbors. A lot of these people like to leave lights on at night. The effect is that every night the sky glows about as bright as the full moon (there's also a full moon tonight, which isn't helping). With curtains I can get a simalcrum of darkness, but I haven't seen (or, rather, been unable to see) real night darkness in months.
Now, I've seen the stars and they're not going anywhere, I don't need to look at the stars every night, but this lack of darkness is taking a toll on me. We're now at a point where there's about the same amount of ambient light from 5PM to 7AM, and the rest of the time there's normal daylight. I've never had any problems with SAD before I moved to New York, so I think it's not the darkness that's bothering me; it's the fact that it never gets really dark.
(6) Sun Nov 05 2006 00:35 TMLMTBGB:
Swamp Swartz is in town staying with us, and we just went to see the Brendan-endorsed play "Too Much Light Makes the Baby go Blind", which is now also Leonard-endorsed. They have an hour to do 30 pieces of sketch comedy and sketch tragedy, ordered according to audience demand. Highlights included "Legoland Theater Presents: The Medieval Epic" and "Bite this, Reality!". Lowlights included preachy political Colbert Report ripoff. There is audience participation (one of my bugbears, or even owlbears), but it's easy to avoid by not sitting at the edges. Dadaism lives! Kind of. The group is called the Neo-Futurists but there was actually no Futurist content unless you count the idea of man as a slave to machinery (in this case the clock).
Also, almost everyone in the cast looked like someone else I'd already heard of. So you could pretend that the skits were being performed by an ensemble of Owen Wilson, Simon Pegg, Pauline Yates, Sumana's friend Steve Schultz, Aladdin Ullah from Uncle Morty's Dub Shack, and Jacquelyn, who I couldn't think of anyone she looks like.
(1) Sun Nov 05 2006 08:42:
I keep getting spam with subjects like "Po..s.sible meeting" and "Fri.en.dship", and thinking that they're advertising hot new Web 2.0 sites.
Sun Nov 05 2006 20:12 Taxonomy of the Programmable Web:
As I've learned more about REST (including formulating the ROA) I need
to go back and rewrite the first few chapters. This entry is part of
my attempt to document what I've learned since then. As I write these
entries keep in mind that I'm not any kind of expert, I'm just a guy
who decided to figure out REST and write a book about it. So if you
disagree or think the something is called the wrong thing, leave me a
comment or email and we'll figure it out.
The first problem is to sort out the terminology. There are many
ways of classifying services, and we're introducing two more in the
book: "Resource-Oriented Architecture", which I've mentioned before,
and "The programmable web", which is a way of saying "web services" without implying Big Web Services, or even saying the word
"services". We got the latter term from the excellent programmableweb.com. (We also introduce "Big Web Services" itself, which is a way of saying "web services" and implying only the SOAP/WSDL/WS-* stack, but I think I'm going to use that term a lot more in these entries than in the book.)
The main work thing I did today was draw diagrams: a taxonomy
diagram. Don't worry, they'll be redrawn by real graphic designers
before they're printed in the book. One or both might make it in; the
Venn diagram is simpler but the taxonomy has examples and chapter
Both diagrams show two decisions I've made for the book: first, we
draw a distinction between Resource-Oriented and Service-Oriented
architectures. Second, we define HTTP+POX as a hybrid of the two
architectures. The former because it's not useful to pit a technology
against an architecture (as in "SOAP vs. REST").
The latter because
the web services described as HTTP+POX, the ones that are
kind-of-but-not-really RESTful, tend to deviate from REST in the
direction of RPC and the Service-Oriented Architecture (rather than
having no architecture at all, which was what I expected). Examples
include the Flickr API, which includes explicit method names
("flickr.photos.search"), and the del.icio.us API, which has special
URIs that you GET to invoke particular methods ("/posts/delete").
Some interesting edge cases: almost all web applications can be
considered HTTP+POX web services. They're usually not all that
RESTful, but they take standard HTTP requests with non-fancy entity
bodies, and serve a non-fancy XML dialect (HTML or XHTML). This is how
libraries like WWW-Mechanize look at the web.
In fact, I suspect the combination of URI- and RPC-based
architectures to form HTTP+POX comes from our experience writing apps
for the human web. You can't do nontrivial REST in a web browser
without Ajax. HTML forms only support GET and POST, they don't let you
set request headers, and they have hard-coded destination URIs (this
is why URI
templates are going to be great).
I used to think that, while the lack of PUT
and DELETE was lame, people who obsessed about those methods as a
determiner of RESTfullness were just being pedantic. But the ROA/SOA
classification shows why it's important: if you have to overload POST,
you end up creating extra URIs which the client POSTs to in different
circumstances. This puts you well down the road to the RPC model. Your
URIs no longer point to resources; they point to procedures you can
call by POSTing. It's natural to keep following that model when you go
from writing a web app for browsers, to writing a web service for
Another edge case is that a website full of static pages is
technically a RESTful web service. It's composed of resources (files),
each with one URI and one representation (the data in the file). Each
URI correctly supports a subset (GET and HEAD) of the uniform
interface. This is how libraries like Beautiful Soup look at the web.
If you look at the Venn diagram you see that the entire
human-visible web (static websites and web apps) is part of the
programmable web. This is quite intentional. People were programming
to the web long before anyone started talking about "web
services". It's dirty work because the human web wasn't designed with
software clients in mind, but sometimes it's the only way to get the
There's one thing in the diagram I'm not clear on. It might be a
minor point or it might be an important aspect of our definition of
HTTP+POX. The question is whether there are web applications that are
so RPC-oriented they cross the limits of HTTP+POX and move in
on the architectural turf of SOAP/WSDL services. I drew the Venn
diagram with web apps that were neither REST nor HTTP+POX, thinking of
really monolothic web apps that only expose a single URI, and do
everything by POSTing to that URI.
The "POX" in HTTP+POX basically means "no SOAP", but what
specifically don't HTTP+POX people like about SOAP? Is it the
complexity of the SOAP message itself? Plain old XML can get pretty
complex too. Or is it the fact that the SOAP message contains
information (like the method name) that they think should go in the
There are also, as one emailer pointed out, problems with calling anything a "web service" if we're drawing distinctions between a "service-oriented architecture" and something else. I'm not sure what to do about that. I'm tossing around the idea of switching that label to "RPC-oriented architecture", but I don't want to introduce yet another term of art.
Mon Nov 06 2006 11:30 open-uri ought to be a REST client:
I spent a lot of time and used a lot of pages in the Ruby Cookbook showing how to use
Net:HTTP to build more and more capable HTTP clients that hid the hairiness of
Net:HTTP. But in truth the
open-uri library, which we only covered a little, supports almost every feature you could want from an HTTP client library: custom headers, proxies, transparent HTTPS with cert validation, even automatic handling of the redirects it's okay to handle automatically. And the interface couldn't be simpler: it overloads
Kernel#open so that you can open an HTTP request like a file, and read the response like data from a filehandle.
I'd like to recommend
open-uri for everything, including as a client for REST web services, but there are two big features it's missing. You can't use any HTTP method other than GET, and you can't send any body data (which makes sense if GET is the only supported method). Lately I've been building on my Cookbook work, coming closer and closer towards a general HTTP client library for Ruby, but really all I'm doing is reinventing
open-uri with two extra features. It would be a lot better to just add those features to
I submitted a patch for
open-uri on this topic a while back but have yet to get any response, even from people saying it's stupid. I'm writing REST clients with
open-uri under the assumption that that'll work by the time the book is published. For instance, here's some code from my Amazon S3 client:
# Saves this bucket to S3.
open(uri, :method => :put)
# Deletes this bucket and all its contents.
open(uri, :method => :delete)
I guess you could argue that these features break the metaphor, that PUTting to a URI isn't really "opening" it, or that it's like opening a file for write access and you should have to write the body data inside a code block the way you do for a file. But c'mon, let's have that argument. I don't want to have to keep telling everyone about fake reimplementations of
open-uri just so they can write REST clients in Ruby. There's also precedent, like
I'd also like to add caching support to
open-uri, like the caching support in Joe Gregorio's
httplib2 for Python. But I'll wait on that until the fate of this simpler patch is decided.
 I doubt this is really the intent of
open-uri, since right now it doesn't support HEAD either. I think the intent of
open-uri is to make it trivial to make an HTTP request from Ruby.
(5) Mon Nov 06 2006 12:05 Amazing Science:
Pulsating Gels Could Power Tiny Robots. Hey, what couldn't power tiny robots?
(1) Mon Nov 06 2006 20:51 Argh:
Have to go another round with the post office. So aggravating.
(2) Mon Nov 06 2006 21:21 Nomenclature:
Some good pushback on the Venn diagram and ROA/SOA dichotomy,
at Labnotes. But also in some emails saying what amounts to: "Why
are you putting 'services' in the name of your book if you then go and
classify REST outside the Service-Oriented Architecture, today's hot
buzzword that has 'service' in its very name? Why are you even saying
'web services' at all if you think REST is different from anything
Good points, and highlighting an increasing source of
uneasiness on my part. Which is good, despite the fact I generally
don't like uneasiness, because it shows it's paying off to embarrass myself by formulating this book in public. People are interested enough in the topic to form uncoordinated revolts around ideas that are wrong or need work.
First a disclaimer about how much this matters: not a whole
lot. This is a book about REST and the ROA. The name of the ROA might
change yet for marketing reasons, but we've got its technical features
pretty well defined. There is a chapter (#1) that covers the
programmable web as a whole, a chapter (#3) whose first half covers
services popularly considered RESTful that aren't really, and a
chapter (#8) that compares REST/ROA to "the other guys".
I was calling "the other guys" "SOA" but that's starting to seem
wrong. My current wild hare is to call them "Message-Oriented
Architectures", though that has a bit of a collision with
Message-Oriented Middleware. That way "Service-Oriented Architecture"
is freed up to describe a higher-level architecture based on providing
and consuming web services (ROA or MOA or both). Which seems closer to
existing usage of "SOA", insofar as "SOA" means anything besides "your
new issue of BusinessWeek is here."
Point is, our taxonomy could change completely and we'd only have
to make real changes to those three chapters (and #8 isn't even
started yet, partially because we're trying to sort this stuff out
first). More important, much more detailed, and hopefully less
contentious, will be our description of what goes on inside the "REST"
part of the Venn diagram.
Anyway, our task here is the Confucian task of the rectification of
names. We're trying to classify the set of techniques and technologies
used on the programmable web. If it turns out to be best described
with gradients instead of subsets, it might be a 2D or 3D map instead
of a Venn diagram or taxonomy.
This doesn't have to be like the Linnean classification system
where everyone signs onto it for all time, but it should be done with
respect for the way "the other guys" see themselves. Sometimes in the text of the book we'll poke fun
at what I call Big Web Services0. But we need to have a credible
story about what Big Web Services really are, how they differ from
RESTful web services, and what lives in between. Ideally someone who
disagrees might say "Well, I wouldn't call it that, but I see
how you draw the distinction."
So here are some unsolved mysteries of our taxonomy:
I don't think anyone will dispute that there's at least one
rival web service architecture to REST/ROA: the RPC architecture that
shows up in many web applications, in web services like Flickr's, and
in XML-RPC. Can we consider this architecture as similar to the
message processing architecture that rarely shows up in web
applications, and that is commonly associated with SOAP? That is,
granted there are differences, do they matter for a book about REST,
or do they both differ from REST in a way we can capture in some
snappy term like MOA?
Are all these architectures mutual opposites, or
points on a gradient?
It it useful to distinguish between the typical robotic SOAP/WSDL interfaces
autogenerated from Java or .NET code at the touch of a button, and the
in potentia SOAP architecture that can be anything, even
Consider the services popularly considered RESTful but seriously
non-thesis-compliant. We currently term those things "HTTP+POX" in
deference to common (kind of common) usage. Is that just another case
of conflating architecture and technology? Is it worth coming up with
another term? And given that there are multiple rival architectures
for web services, do these not-quite-RESTful services consistently
deviate from REST in the direction of some other architecture, or are
they just freakish one-off mutants? Are they the missing links on a
gradient between the rival architectures?
0 Said like in one of those political ads with lots of
black-and-white closeups: "Senator Bedfellow doesn't want you to know
about his millions in contributions from Big Web Services. When the
FBI came knocking, he started shredding the XML documents. But he
forgot to shred the envelopes. Senator Bedfellow: wrong on URIs. Wrong
for the web."
Mon Nov 06 2006 21:56:
As is all the rage, I have started posting book-related links I want to find or track under the del.icio.us tag restbook. If you want me to see a link, you can post it there. If you're secretly writing a REST book of your own and my tag cramps your style, let me know and we'll settle the namespace collision on the field of honor. Or the field of me renaming my tag to "oreillyrestbook".
(6) Tue Nov 07 2006 22:21 Taxonomy of the Programmable Web! Part Deux:
I know you're all for some reason anxious for the next report on my
book progress. Well, in public it's all high-level philosophy but
proxy hacks so I can finish "Ajax Applications as REST Clients".
However Sam and I did have a long IM conversation today, and
cleared up a lot of taxonomy issues, as well as some of my
misunderstandings about SOAP. I feel confident enough now to take
another stab at my taxonomy of the programmable web. I got about
halfway through before Ben came over to watch Battlestar Galactica,
and that half is what I present to you tonight.
Again the disclaimer: though people will argue about these topics
until the end of time, for purposes of this book we just need to get a
coherent story about what it is we're cutting away as we zoom in on
the programmable web to focus on the parts called "REST" and "ROA".
There are two major architectures on the programmable web. One is
oriented around the passing of messages from place to place, and one
is oriented around the manipulation of server-side objects called
resources. We're (still tenatively) calling these the Message-Oriented
and Resource-Oriented Architectures. Both architectures have real web
applications and real web services to their credit.
These architectures can show up elsewhere than on the web, but
we're not concerned with that. On the programmable web a service under either architecture uses the
same underlying technologies: HTTP; a data format like XML,
JSON, or form-encoded key-value pairs; and at least one URI.
Because they're built on HTTP, both architectures have a request
cycle where the client asks the server to do something, and the server
does it and sends a response. But we've found two questions which the
MOA and the ROA answer differently:
- How is the request scoped? How does the client tell the server
what part of the application it wants to operate on? Let's say the
purpose of the request is to fetch some data. Why should the server
send back data X instead of data Y?
- How does the client convey to the server what it wants the server
to do? Why should the server send the requested data instead of
modifying it somehow?
First a brief digression. When you send an HTTP request, you have
two main options as to what to send in the entity-body. You can just
send your data, or, if your data is an XML document, you can stick it
in a box first. The name of the box is SOAP.
Just to avoid confusion: "SOAP" here is referring to the SOAP standard, not to the things people do with SOAP in the real world (that comes next). Sam says: "There isn't much to SOAP. It is three elements and a fault descriptor. Oh, that, and a world view." I'm just talking about the three elements and the fault descriptor. The worldview is the MOA.
Why would you stick your XML document in a box? Well, there are a
variety of stickers that can be slapped onto the box without
disturbing the contents. These stickers are the WS-* stack. That's the
With that in mind, let's consider how the Resource-Oriented Architecture answers the two
questions. A client for an ROA service scopes its request to a
resource, by sending its request to a URI that identifies that
resource. In an idealized ROA application there's one resource for
every part of the application you might want to manipulate. Every
resource has at least one URI, and you've got to send your request to
some URI, so you might as well designate your resource by its
URI. The URI goes in a special place in the HTTP request and can't be
confused with anything else.
When conveying what it wants an ROA service to do to a resource,
the client is restricted to a small and standardized list of
methods. These methods are the famous HTTP GET, PUT, etc. Again, the
HTTP method goes in a special place in the HTTP request and can't be
confused with anything else.
If the client wants to convey an action that's not on that list,
the problem is almost always that they've chosen the wrong
resource. The service ought to expose some other resource for which
the client's desired action translates naturally into one of the
standard methods. The service might not actually expose this resource,
but that just means the service can't do what the client wants. It's
no different from the aggravation of a C library that's missing the
function you need.
(There are edge cases I don't really understand, about overloading
POST for atomic operations that span resources. I'm still trying to
figure this part out. I think I may end up modelling this as a tiny
MOA architecture inside the ROA.)
Now, depending on the service, when you need to send a document with your request, you might just send it as is, or you might stick it in a
SOAP box first. The second possiblity, is, AFAIK, only theoretical. I
don't know of any services I would describe as ROA where the client
sticks its entity-bodies in a SOAP box before sending them.
This is partly for historical reasons. It's partly because it's
simpler for the server to accept the entity-body as a document,
instead of parsing it into a SOAP box covered in stickers, plus the
"real" document. But it's mainly because HTTP already has stickers
(HTTP headers). An HTTP request or response is already a box that can
contain data and have stickers slapped on it.
HTTP stickers are more restricted in form than SOAP stickers, but
they're good enough for most purposes. To the extent that ROA service
programmers covet the features of WS-* stickers, they tend to devise ways of
representing the same information in HTTP headers. Example: WS-Security's
WSSE "ported" to the ROA as the X-WSSE header.
OK, enough about the ROA for a while. What about the MOA? And where
do popular acronyms already in common usage fit in? Tune in tomorrow
for the action-packed conclusion.
(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
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."
(1) Wed Nov 08 2006 19:11:
Continuing my habit of clicking on Kris's ads I found the comic strip Station V3, which combines a ShaBot-esque sense of gag-based humor with a pretty good psychological study of being posted to a space station where nothing ever happens and you're surrounded by other dysfunctional people. A dimension that could be exploited to great effect by any number of other big-name media brands (I'm looking at you, Beetle Bailey), but never seems to be.
Strip includes cute fishlike aliens, and outdoes Battlestar Galactica in the low-tech science fiction aesthetic sweepstakes by having not just big clunky phones but big clunky payphones. Also you probably know this, but if you like science fiction comics with big space opera arcs and good character development you should check out Schlock Mercenary.
(7) Thu Nov 09 2006 12:50 Return of the Son of Taxonomy of the Programmable Web:
Previously, on Taxonomy of the Programmable Web, I put out a
description of the Resource-Oriented Architecture based on its answers
to these two questions:
- How is the request scoped? How does the client tell the server
what part of the application it wants to operate on? Let's say the
purpose of the request is to fetch some data. Why should the server
send back data X instead of data Y?
- How does the client convey to the server what it wants the server
to do? Why should the server send the requested data instead of
modifying it somehow?
Now I'm going to put out a description on the same principles of
the Message-Oriented Architecture. Then I think I can make a case for
how to classify weird cases like HTTP+POX.
To state the obvious (though it stops being obvious if you or we
call the MOA something else), the Message-Oriented Architecture is
about passing messages back and forth. Client sends server a message,
server takes some action and sends client a message in response. A SOAP box with stickers on it is an example of a message. An HTTP request with headers is also an example of a message.
In an ideal MOA there is no information outside of the message. So if the message is in a SOAP box being transmitted over HTTP, then all the features of HTTP are just distractions and should be used as little as possible. There should be no leakage from the message into the transport protocol.
In the ROA, the fundamental server-side object is the resource. An
ROA service usually has an infinite number of resources. In the MOA,
the fundamental server-side object is the message processor, sometimes
called an endpoint. A MOA service exposes a small number of message
processors: usually one. A message processor is the thing that has a
URI (or, possibly, the thing that can be the target of the
WS-Addressing SOAP sticker).
Side note: A resource is just a message processor with a very limited
vocabulary. So there's a pretty easy conceptual translation between
the ROA and the MOA. This makes sense because HTTP is itself a
message-oriented protocol. Of course, almost all ROA services expose
too many "endpoints" to list. You either generate their URIs according
to a rule, or you follow links in a document the server sends you.
An MOA might have ten or 200 or a million endpoints, but it's not
ROA unless it has an endpoint or "resource" for every object the
client might manipulate. Any service that exposes an infinite number
of endpoints has at least some of the ROA in it.
This ties back into the famous triangle
of "nouns" (resources), "verbs" (HTTP methods), and content types. The ROA constrains the "verbs" and
lets the "nouns" run free. The MOA constrains the "nouns" and lets the
"verbs" run free.
Side side note: an ROA service can contain a finite number of
endpoints, but only if there's a finite number of objects the client
might manipulate. A static website (like your cat's homepage, or the
site that serves Google Maps image tiles) is an ROA service with a
finite number of endpoints. A web service version of Parmenides's model of the
universe would only have one endpoint, because there is only one
proper object of discussion.
Now let's consider how the MOA answers the two questions:
How is the request scoped? Why should the server do x to data D1 instead of data D2? Well, in the URI it's scoped to the message processor. If your MOA service is actually ROA then that's all you need, because the "message processor" is the "resource" is the part of the application you're operating on. Otherwise,
you need some additional scoping, and this is done by putting
information in the message itself. This might be in the box or it
might be in one of the stickers; the details don't matter.
How does the client convey to the server what it wants the
server to do? Why should the server do x to data D1 instead of doing y to data D1? This too is scoped by information within the message
itself. Again, this might be in the box or in one of the stickers; it
doesn't matter to the MOA. Unlike with the ROA, the vocabulary of this
sort of information is not constrained at all. If you constrained it
you'd need to create more endpoints to handle the same actions with
the more limited vocabulary, and you'd move towards the ROA.
Since in the MOA both of these pieces of information go into the
message, there's a tendency to conflate them, and indeed that's what I
used to do.
To recap from last time: the ROA puts scoping information in the
URI, and puts the action information in the HTTP method. The big
exception seems to be overloaded POST, where the action information can go in the
entity-body. I'm now fairly certain that overloaded POST in the ROA is
best described in terms of the MOA; I'll try to cover that next time.
Now I'd like to talk about a common design style for MOA services:
the RPC style. In an RPC service, the scoping information corresponds
to the information that would identify an object if this were an object-oriented program. The action information
corresponds to a method that should be called on that object. As is
proper with the MOA, both of these go into the message.
The message also contains some additional information, which
corresponds to arguments passed into the procedure. The scoping information can be found among these arguments: things like the bank account number or the user ID. This is because an RPC service isn't really object-oriented. If it was, you'd be able to work directly with the objects (as, say, resources) instead of going through message processors. But with a little work you can get the same kind of "fake" OO you see in the GNOME project's C code, where the first argument to every function is a pointer to the "object". I put "fake" in scare quotes, possibly sending the most mixed message ever, because I think you can do real OO design in a non-OO system. But it looks strange, and you have to do work to get it.
In an RPC-style service, the HTTP request-response cycle is used to
simulate a method or function call in a programming language. The request is the
method invocation, and the response contains the return value of the
method, or the exception it throws.
We all know that method calls are not neccessarily simple stuff
where I ask you for information and you return it in a data
structure. This "method call" might do anything: fetch information,
store information, put a job in a processing queue, set up callbacks
for later, etc. The response message might contain useful information,
it might describe an exceptional condition, or it might just be a
formality. If you register a callback the real data might be coming in
later through the callback. So saying "RPC style" is not a negative
value judgement about the capabilities of the style.
Let's take an easy case: XML-RPC. It's obviously an MOA
architecture, since the only URI in an XML-RPC service is the URI
to the XML-RPC service. It also rejects HTTP headers, methods,
and status codes almost entirely, preferring to convey all information
information in its XML message document.
It's also obviously an RPC architecture, because 1) it says so
right in the name, and 2) its messages are full of incriminating tag
Now, what about SOAP? Is SOAP an RPC style? No, that's a category
error. SOAP came from XML-RPC (more accurately: they have a common ancestor) but they aren't the same kind of thing. XML-RPC is a way of describing method calls; SOAP is a way of
sticking a message in a box and putting stickers on the box. This
makes it useful for any MOA application, but it doesn't make it RPC.
So, riddle me this, Batman: how come basically the entire installed
base of services that use SOAP also use the RPC style? Why does the average programmer think SOAP and then think RPC style?
SOAP is the message format of choice for automated tools that take
Java or C# code you've already written, and with one
click turn it into a web service. These tools are to web services as
FrontPage is to web pages. The resulting "web service" exposes only
one URI and accepts methods only in a very specific form that a person
can't comprehend without a detailed map (a WSDL file) and a software
tool on the other side (a WSDL client) that can read the map so you don't have to.
When the software tool is done reading the map it's reconstructed something like the
method signatures of the original Java or C# code.
This is why REST people dislike these services so much, and why
that dislike often spills over into SOAP. This is why people tend to
think that anything that doesn't fit this model is "REST". This is why
I say these services are not really on the web: they're looking out at
the web through a little peephole. To get any information out of them,
you have to construct a very specific document, and then you have to
put in a box and put the right stickers on it.
These services have the same design as XML-RPC services. They use
XML Schema instead of XML-RPC's idiosyncratic data serialization
format, and they use WSDL instead of the
extension to XML-RPC. All the work done to make SOAP nothing but a good way of putting an XML document in a box and slapping stickers on the box, has passed these services by.
I don't like this because it's ugly and it pollutes the web. SOAP
fans don't like this because it conflates SOAP with RPC when what
they use SOAP for isn't RPC at all. I'm not really clear on what MOA
styles they are using if not RPC, but I don't think it's going to come up a lot
in a book about REST and the ROA, so I can just leave them to it and
have Sam act as my lookout in case anything relevant to the book
Who's the culprit here? I think it's those tools. They make it easy
to get a web service that has the same interface as your code (that'd
be a Procedure-Call interface that works Remotely), disregarding the
fact that the architecture of the web doesn't look like that. Combine
this disconnect with the complexity of the interface and the
idiosyncracies of the tools, and you've made it easy for someone else
to work with your service if they've got the exact same setup, and
very difficult otherwise. This is pretty disgraceful since the
real-world power of the web comes from its ability to connect everyone
The secondary culprit is WSDL. WSDL doesn't enforce RPC but it
makes life easy for tools that want to force SOAP into an RPC
mold. Sam is ambivalent
about WADL. I suspect he's afraid that WADL will make it easy to
force HTTP into an RPC mold, that tools for doing this will
proliferate, and that we'll never see resources again. Sure, WADL
makes you specify your resources, but a smart tool could easily
subvert that and create services with a single "resource" that handles
a whole bunch of method calls.
I think the scenario I've ascribed to Sam is not inevitable. A lot
of the mess we see today comes from historical contigencies like
SOAP's heritage in XML-RPC. But to prevent a future without resources
we need a basic book that's willing to go out and fight for them. It
means we need to straighten out the terminology—even if only
informally and we only use the terminology locally—so we can
create a frame for our argument.
Next time: HTTP+POX.
Fri Nov 10 2006 16:22:
OK, here's the deal. On any given day I can do book writing or I can write one of those big ole weblog entries. Today was book writing day. I got the "Writing Clients" chapter more or less done, bringing us to our milestone of having drafts of half the chapters. This is one of those milestones where I get paid, so I'm happy.
The Ajax chapter is also done, and I'd like someone who knows more than I do (ie. something) about Ajax to look at it.
Fri Nov 10 2006 21:06:
Picked Sumana up at work and walked down to Chelsea for dinner. My first choice, "Elmo", had no vegetarian entrees, so we went to a nearby place called Food Bar (not Foo Bar) that was good. We then walked to the Strand, where giveaway copies of books go to die, and Sumana found some cheap books she wanted. A nice evening out and a relief from looking at a computer screen all day.
Sat Nov 11 2006 23:27 Picasso:
Today hung out with Evan and his father, which was a lot of fun. We went to the Whitney (conveniently hidden in a totally random block of Manhattan) and saw the Picasso exhibit. The theme was to have a Picasso, and then a bunch of paintings by other artists (Lichtenstein, Pollock, Jasper Johns, etc.) who'd ripped off the Picasso. It was pretty neat, and there was an Edward Hopper exhibit as a bonus. That guy's sketches are amazing.
There were two Picasso paintings (the really famous ones) that the MOMA owns and wouldn't lend to the Whitney. So the exhibit just put up the ripoff paintings and had tiny passive-aggressive reproductions of the originals along with explanations along the lines of "Girl Before a Mirror, in the collection of the Museum of Modern Arts since 1944, the cheap bastards!..."
(5) Sun Nov 12 2006 20:07 The Rite of First Sale:
Earlier I declared, "I've never done so much work for a hundred dollars." Well, I'm moving up in the world, because now I've never done so much work for two hundred dollars. I got email today saying that Futurismic bought my story Mallory!
This is great news for me as it demonstrates that I can write fiction people will buy. Look for it sometime next year, probably a little before the REST book is published.
(1) Mon Nov 13 2006 12:56 Abbot and Costello Meet the Taxonomy of the Programmable Web:
So far I think I've made a coherent case for classifying RESTful and
resource-oriented services on one side of the Venn diagram, and
message-oriented services on the other. The RESTful and
resource-oriented services keep the scoping information (why should
the server send you some dataset instead of some other dataset?) in
the URI, and action information (why should the server send you the
dataset instead of modifying the dataset?) in the HTTP method.
The MOA field is dominated by RPC-style services, most of which use
SOAP messages constrained by WSDL files. The client communicates its
desire by sending a message (a box with stickers on it) to a message
processor, which unpacks the box to find both the scoping information
and the action information.
We've got two edge cases to explain: overloaded POST and so-called
"HTTP+POX" services. It's been said (see link at end) that I
shouldn't try to fit HTTP+POX services anywhere at all because they're
just a mishmash, but I press on.
We've also got an unexplained coincidence. I've been describing
SOAP as a way of putting a document in a box and slapping stickers on
it. But you can look at HTTP the same way. The HTTP request (or
response) is the box; the entity-body is the document; and the URI,
headers, method name, and response code are all stickers.
HTTP+POX, as they say, is a mishmash, but I think I can identify
the things it's a mishmash of. An HTTP+POX service is a
message-oriented RPC-style service that uses HTTP as the box format,
rather than using SOAP.
This is most obvious if you look at how you modify the dataset in
HTTP+POX services (I'm using the del.icio.us API and Flickr's
allegedly "REST" API as examples). You either send a GET or an
overloaded POST to a URI that's not a resource: it's a
description of the procedure you want to call. There's a message
processor for every operation, rather than just one (as generally
happens with SOAP+WSDL services), or one for every object on which you
might want to operate (as with resource-oriented services). Examples:
The confusing part is this: when the RPC method you're calling is
"get some data", the HTTP method is usually GET, and the arguments to
the RPC method usually go into the URI. This URI designates a
resource, and you can GET a representation of that resource! This is
why I thought that HTTP+POX services are hybrids of the
resource-oriented and message-oriented architectures. In many cases,
the message is one you'd send if you were using the uniform
interface to get a representation of a resource. The service may not
have been designed with resources in mind, but this part of it is functionally
Examples. Consider an endpoint of the del.icio.us API:
https://api.del.icio.us/v1/posts/get?tag=restbook That doesn't
have the same ring as
it's the same kind of URI. Those are two URIs to two representations
of the same resource: "my recent posts tagged with 'restbook'". There
are infinitely many URIs of this form, each identifying a different
supposed to interpret that as a remote procedure call, but it's also
the URI to a resource: "Pictures tagged 'penguin'". Another URI to a
different representation of the same resource is
http://flickr.com/photos/tags/penguin. Even a URI like
is the URI to a resource, though a better URI for the same resource
We have our own recommendations about how to structure URIs in a
resource-oriented service, but it's pretty small-minded to say that
services aren't resource-oriented just because their URIs look funny
and contain things that look like method names (like "get" and
"method=flickr.photos.search"). From a functional standpoint, these
services stop being resource-oriented when they stop using
resources. And, in general, they stop using resources when it comes
time to modify the data set.
The method names in those URIs are useless to the extent they
agree with HTTP's uniform interface. The "get" and the "flickr.photos.search" basically mean HTTP GET, and the
client's already using GET. When those strings become useful ("add" or "flickr.photos.comments.deleteComment") it's because the RPC interface supercedes the uniform interface. The URI can no longer be
conceived as pointing to a resource.
could be one of many URIs to the resource "comment #100". Maybe the
"method" argument is just random junk. Maybe if you GET this URI you
get the comment, and if you delete this URI you delete the
comment. But of course if you GET this URI you delete the
comment. This URI doesn't identify the comment: it identifies an
operation on the comment. That's not a resource. It's just a procedure
You can see this by looking at web applications. A web application
like a search engine is pretty resource-oriented. It exposes an
infinite number of URIs that slice up the search engine data in
various ways: by query, by page, by language searched. All of these URIs point to resources. You can't see any cracks between the message-oriented
and resource-oriented models, because 1) the "messages" you're sending
are standard HTTP requests, and 2) you can't modify the search
engine data through the web interface, so you only use GET and you use it as intended.
Then again, consider NewsBruiser, the weblog program that publishes
these words. I wrote NewsBruiser before the term "REST" was coined,
but it's pretty typical of examples even today. I've got URIs like
/nb.cgi/configure, and so on. In general GETting one of these
URIs gives you an HTML form, which you fill out and POST to the same
URI to modify the data set.
Even putting aside the fact that you can't do PUT or DELETE with
HTML forms, this is a very RPC-oriented application. It's got method
names in the URIs. Yet when you're not changing the application you're
using URIs like
/nb.cgi/view/nycb/2006/11/03/1. That's got a
method name ("view"), but it's redundant with the name of the HTTP
method (GET), just like with the del.icio.us and Flickr examples. The
rest of the URI describes a resource: the second News You Can Bruise
entry of the third of November, 2006. Indeed, I've got a rewrite rule
that cuts out all the redundant and default data so that you can use
So that's HTTP+POX. It looks like there are two main paths to this
architecture. You might come to it by designing web services on the
exact same principles as web applications. This overlaps with the
resource-oriented architecture when that architecture congrues with
the capabilities of web browsers (GETting data from resources
identified with URIs, sending data to hard-coded locations). It
departs from the resource-oriented architecture when it comes to
things you can't do with a web browser (using PUT and DELETE instead
of overloading POST so much, sending data to URIs that the client
Or you might come to it through an attempt to simplify the RPC
style. You might be doing pushbutton SOAP+WSDL services and one
day say "screw only having a single endpoint; I'm going to have an
endpoint for every procedure and it's going to be identified in the
URI and then I won't need WSDL". Or you might say "screw putting an
XML document in an XML box; I'm already using HTTP, I'll just use it
as my box and then I won't need SOAP".
Now a word about the name. I've decided "HTTP+POX" is inaccurate and I think
I won't use it in the book except insofar as I need to translate
real-world terms into my wondrous precise terminology. Here's the
problem: like "AJAX" of old, "HTTP+POX" hard-codes a reference to XML
where there might not be any XML.
To reiterate one of my earlier points in new language: what's
"Plain Old" about Plain Old XML? What's "Plain Old" is that it's a
document, not a box with a document inside it. You've already got a
perfectly good box: the HTTP request. But that's a statement about the
box. "POX" is a statement about the contents, and
those don't have to be XML. An HTTP+POX web service might serve plain
text, JSON, HTML microformats, or graphic files in an HTTP box. This holds even if you don't buy my argument that HTTP+POX is an RPC-style architecture.
I can think of two different names. One involves doing what they did to
AJAX and lowercasing the "POX", making it a word instead of an acronym:
HTTP+Pox (HTTP can stay an acronym because you are using HTTP and only
HTTP). This has the advantage that it's an almost invisible
change. But depending on how cocky I feel about my classification of
these services as RPC services, I may try to push the term
HTTP+RPC. Because "Pox" doesn't mean anything, and I don't like the
trend towards stripping acronyms of their meaning when it becomes
inconvenient (as also happened to SOAP).
The next installments will cover what to do with terms like
"Service-Oriented Architecture" in the face of definitions
that would a priori prevent REST from getting any of the
pie, and also finally tackle the question of overloaded POST in
resource-oriented architectures. I think it's going to be a while
until the last one, at least, shows up. Before I try to figure out
overloaded POST I want to incorporate into the book text my thinking
in the series so far.
(2) Tue Nov 14 2006 00:31:
This one's pretty short; I just want to respond to Pete's
entry about the term "SOA". I have largely bought into Assaf's
assertion that defining resource-oriented services out of the SOA
cuts them away from a large source of largess and buzz for no real
reason. I don't really care about "SOA", but I do care about people spending
money in the right places, so I want to leave the rhetorical ground
open for those who can make that happen.
Pete quotes Anne Thomas Manes as saying:
Service oriented architecture (SOA) is a software design discipline in
which application and infrastructure functionality are implemented as
shared, reusable services.
As Pete points out this definition has a dependency on the
definition of "service". Pete's definition is "a network available
collection of related operations".
Okay, I'll buy that, and I'll also buy a $0.50 contract on Pete's
"a resource is not a service". I'd say a resource is a service, albeit
a very limited one that can only operate on one piece of data. An RSS feed is a good example of a one-resource service. But a
collection of resources is definitely a service. In fact, "service" is what we call a collection of related resources.
A single resource can't have arbitrary operations, but you can
expose arbitrary operations by exposing combinations of
resources. It's not the same design as an RPC service, but only
intertia associates RPC with "service-oriented" in the first place,
and a service-oriented system could easily consume a mix of
resource-oriented and RPC-style services.
Wed Nov 15 2006 20:40:
Spent most of the day doing Ruby Cookbook errata (new printing going out next week), which was pretty humbling. Also converting the REST book to Docbook, which is AGGRAVATING. Not least because I need to rewrite the first part of the book anyway and I keep conflating the Docbook conversion with the rewrite.
PSEUDO-UPDATE: I finally finished the errata and decided to put up an update. Then I saw I had saved this entry as a draft and not published it. So this isn't a real update. Incidentally, the previous entry was one I wrote back in August and saved as draft instead of publsihing.
(2) Sat Nov 18 2006 00:12:
Sorry for no NYCB; been converting the book to Docbook and tearing apart the first part so I can stick Taxonomy of the Programmable Web stuff into it.
Sun Nov 19 2006 09:40:
Susanna and John are here for Thanksgiving and sightseeing. Susanna has a baby Beet inside her, as promised. Today we go to the park and the Met.
(4) Tue Nov 21 2006 10:12 Borges: A Life:
Been reading this book (the Williamson one) in stolen moments because it needs to go back to Rachel after Thanksgiving. It starts out really slow and boring but about 2/5 of the way in starts to ramp up and gets very interesting. Unfortunately 2/5 of the way is 200 pages, and it turns out you need most of that stuff because it's describing what later turns out to be the neuroses Borges can't get rid of for the rest of his life.
Wed Nov 22 2006 22:04:
Tomorrow: Susanna and I are in charge of Thanksgiving. It's going to be great.
I've got much of the REST book converted to DocBook and am putting what I write online. Send me email if you want to do review.
Wed Nov 22 2006 23:03:
From email conversation with Danny:
> > I SHALL TAKE THE CHALLENGE!
> Join me or die! Can you do any less?
I can't think of any way I could do less in general, but I'm always on the lookout...
Fri Nov 24 2006 19:15:
There are some kids who come out and play in the concrete "backyard" of the apartment building across from ours. That "backyard" is also where people stick their trash, and recently the kids' play has incorporated the trash.
There are two different reactions to this: "We must stop them!" and/or "I remember doing that sort of thing." I am in the latter camp because the kids seem to know what they're doing; they play with the abandoned furniture instead of rooting around in the trash bags.
Sometimes it I think they know what they're doing a little too well. A while ago someone threw out an old wide-screen TV (a big box for a plasma-screen showed up around the same time). The other day some kids were sitting in front of the TV, coloring with markers and pretending to watch TV.
Sat Nov 25 2006 17:21 Post-Thanksgiving Breakfast:
Bowl of stuffing with fried egg on top. Delicious.
(2) Sun Nov 26 2006 18:27 Cloisters:
Today Sumana and I went up to the tip of Manhattan and visited the mini-Met museum of medieval art at the Cloisters (actual monastery cloisters imported from Europe). It's in a really nice park (Fort Tryon) so we also had fun walking around the park, and had a pretty fancy brunch at the in-park restaurant, New Leaf. We watched the sun set over the George Washington bridge.
Some funny bits of conversation from our day:
"Wel-come to the social! Zune you'll be dead!" <-Cryptkeeper voice
"I don't know how all these little stores can survive."
"They survive because there are millions of people here, and they all demand breakfast sandwiches!"
"And punctuation errors."
"Yes. They 'demand' breakfast sandwich's."
I got a Met membership so that I can go whenever I want without having to pay the exorbitant "recommended donation", or having to deal with the passive-aggressive consequences of trying to get in for less. Last time I was at the big Met I found out that my favorite objects d'art in that museum, the ancient Chinese office supplies, are part of a temporary exhibit that goes away in January. Go see that exhibit! It's great! And it also has a bunch of cool Xu Bing art that I just discovered last time.
Sun Nov 26 2006 22:50 Quick Restaurant Review:
Annie's on 3rd Avenue between 78th and 79th. A little bit expensive, but good food and lots of it. Fairly vegetarian-friendly. Good place to eat after seeing museums.
(2) Mon Nov 27 2006 16:52:
Misc. tidbits from conversation last night:
- Brandon Bird should paint an Adoration of the Magi in which the Magi are Kirk, Picard, and Sisko.
- Brandon Bird already painted a Last Supper, but perhaps some British equivalent to Brandon Bird could paint a Last Supper featuring all the incarnations of the Doctor from Doctor Who.
- Dun-da-dun-da-dun. Investor Gadget.
- It's well-known that a lot of the intro songs to James Bond movies are really lame and don't even have the same names as the movies. I now plan to write a song cycle of 21 songs, each with the name of a Bond movie.
(3) Mon Nov 27 2006 20:41 Karaoke For Beginners:
- "Meow Mix Commercial" (theme)
(1) Wed Nov 29 2006 16:44 Shake Shack:
Today I went to the Shake Shack on my way to the farmer's market. I went because it's supposedly a New York tradition, and pretty soon it closes until spring. I had a hamburger and a "concrete", which is a sort of thick milkshake made from frozen custard and extra stuff.
I've been to a frozen custard place before: Carl's in Fredricksburg, Virginia. So I knew what to expect. And it was good, except here I ordered a concrete that included Valrhona chocolate disks or whatever they're called. I didn't really know what they are so I said "Disks? Sign me up!" Then I got the concrete and remembered what Valrhona chocolate disks are. Those guys are great... FOR BAKING. For putting in frozen drinks they're not so great. It's like putting chopped-up Snickers bars in a milkshake and then crunching on frozen Snickers bar all the time you're drinking it. When you get a concrete, stick to extra things that are soft.
Hamburger: eh. I probably shouldn't even have gotten this since Shake Shack had about 150 health code violations (not an exaggeration) last time it was inspected. It wasn't very good. Andy and I have been going out on excursions where we try out the city's hamburgers, and Shake Shack is pretty lousy. I'd rate it below Burger Joint (trashy take-out burger restaurant in fancy Parker Meridien hotel, primarily famous in class-obsessed New York due to its class-transvestitism; there are celebrity autographs on the wall inc. Stephen Colbert's), which doesn't even use real hamburger buns. In conclusion: Shake Shack is for frozen custard with soft things in it. That stuff is good and you're likely to run afoul of fewer health code violations.
If you're curious, best hamburger discovered so far: Zip Burger at 300 E 52nd. They have Belgian fries too, and non-perfunctory veggie options.
Thu Nov 30 2006 09:22 1995 Follies:
Sumana did a presentation for her corporate finance class where she pretended she was a Morgan Stanley investment banker trying to get people to invest in Netscape pre-IPO. I suggested she start off by saying "I bring you tidings... FROM THE FUTURE!". She said "That's basically what she [the professor] explicitly said we couldn't do."
So instead she talked about Netscape's server business and the promise of the web and blah and blah. There were Powerpoint slides, which seems somewhat anachronistic for 1995.
Anyway, this morning we were doing a postmortem, and the conversation turned toward the mid-90s integration of the proprietary online networks (Compuserve, AOL, etc.) into the Internet. Specifically, the common shunning of AOL users. Any mention of shunning calls to Sumana's mind Gentlemen's Agreement, specifically the scene where Gregory Peck can't get a room at a New England inn.
"Yes, I'd like a room." <- Rugged Gregory Peck voice
"Certainly, sir, I think we can accommodate you. If you'll just put your email address down to get on our mailing list."
"Ah. Oh, I see, sir. I'll be quietly shunning you now, sir. It's a free service we provide... FOR THOSE WE DON'T GIVE ROOMS."
Thu Nov 30 2006 22:08:
Well, my performance in this year's Nethack tournament was pretty lousy, mainly because it wasn't until around Tuesday that I thought "Hm, what would be fun to do in spare moments right around now? Oh yeah, Nethack." I did have one good character but killed her off stupidly.
Almost all of REST Web Services so far is rewritten and in Docbook. I planned to get the whole thing done by the end of the month, but that's just another goal I didn't meet: still have half a chapter to redo. I'm very happy with the first 5 chapters so far, though. Total length in O'Reilly's stylesheet is 200 pages. Again, email me if you want to read the REST book as I write it.
|Unless otherwise noted, all content licensed by Leonard Richardson|
under a Creative Commons License.