Fri Jun 01 2007 08:57: InfoQ, the famous "enterprise software development community", has an interview with Sam and me, as well as an excerpt from the book. Enjoy!

Later today on this weblog: still more REST crap!

(6) Fri Jun 01 2007 14:30 How's My Driving? #1: Microsoft Astoria: Sumana wants me to post some analyses of web services and talk about how they are or could be made more RESTful. Alex Barnett wants me to look at Microsoft's Astoria project (so does Microsoft, apparently, since they named it after where I live). I love it when a plan comes together. Here is some free consulting for Microsoft, based entirely on my readings of white papers ("overview" and "using").

I wrote this entry by going through the two white papers and trying to discern what resources the system exposed, what parts of the uniform interface they support, what representations are served and accepted, and how resources link to each other. This is the same approach I took when analysing the Atom Publishing Protocol for RWS. I'm pretty sure I got everything right, but I'm not totally sure about the association resources. I've presented my findings in a form much like the one I'd like to see if I was trying to figure out how a RESTful web service worked. I hope this helps.

Introduction

Astoria is a framework for a certain class of web services: those that expose access to tables and rows in a database. In this regard it's similar to ActiveResource. The resources exposed might not correspond exactly to the underlying database objects, but they will look like database tables and there will be some kind of mapping to a real database.

The "overview" whitepaper starts out covering some of the ground covered in RWS chapter 11. It points out that Ajax applications have a different architecture than traditional web applications. They're GUI applications where the GUI events are handled by an invisible web service client. Astoria wants to provide the services those clients will access.

Astoria "uses URIs to point to pieces of data" (ie. resources). Astoria's "data services" are "surfaced to the web as a REST-style resource collection that is addressable with URIs and that agents can interact with using the usual HTTP verbs such as GET, POST or DELETE." So far so good. They talk the talk.

Meet the Resources

An Astoria service defines six basic kinds of resources. A lot of them correspond directly to a resource type in ActiveResource and/or the Atom Publishing Protocol. This makes sense because all three are solving similar problems: exposing collections and the objects in the collections.

1. The "Entity-set list" resource, located at the service root (/data.svc, for example.) This is not explicitly called out, but it has a URI and responds to GET, so it's a resource. This is a simple list of the available entity-sets (see below). It's analagous to the APP service documents.
2. "Entity-set" resources. These correspond to a table in a database. ActiveResource has these too; they're analagous to APP's collections. An entity-set is identified like so: /data.svc/Customers. Notably, this is where pagination and "order by" are supported.
3. There are virtual entity-sets which correspond to a query on a database table: /data.svc/Customers[Valuation gteq 5000000]. This is analagous to the GData extensions to the APP that add query capability to APP collections.
4. "Entity" resources. These correspond to rows in a database table. ActiveResource has these too, and they're analagous to APP's members.

   A entity is identified with its collection name and then some kind of unique index: maybe /data.svc/Customers[4] or /data.svc/Customers[ALFKI]

5. There are scoped entity-sets which are associated with some entity. /data.svc/Customers[ALFKI]/Orders shows all the "order" entities associated with a particular "customer" entity. /data.svc/Territories[99999]/Employees shows all the "employee" entities associated with a particular "territory" entity.
6. Finally, for many-to-many relationships there are separate "association" resources. /data.svc/Territories[99999]/Employees[3] shows the relationship between territory 99999 and employee 3. Presumably it's also available as /data.svc/Employees[3]/Territories[99999].

   (Note: the white papers also talk about a non-resource "association" that's part of the state of an entity. It's a link from one entity to another, as part of a relationship that's not many-to-many. For instance, every order associated with Customers[ALFKI] will contain a link in its representation to Customers[ALFKI]. These associations are not resources, because they don't have their own URIs; they only show up in representations of entities. When I say "association" I'm talking about association resources.)

The uniform interface

What do other frameworks do? The APP and Rails define GET and POST on a "collection" resource; and GET, PUT, and DELETE on a "member" resource. The APP defines GET on a service document. Where Astoria has similar resources, it exposes the same interface. The only part that's difficult to explain is the difference between POST on a regular collection and POST on a scoped collection.

The "overview" white paper has a confusing paragraph about Astoria's use of the uniform interface (the one that begins "For URIs that represent a specific entity...") which is either wrong or very poorly worded: I read it as saying that entities respond to POST, which doesn't make sense. Here's what I got from the "using" white paper, in convenient table form:

Resource	GET	POST	PUT	DELETE
Entity-set list	X	-	-	-
Entity-set (collection)	X	X (Create a new entity)	-	-
Virtual entity-set	X	-	-	-
Entity (member)	X	-	X	X
Scoped entity-set	X	X (Create an association between two entities)	-	-
Association	X	-	X	X

I'll just explain "Create an association between two entities," shall I? Here's a scoped entity-set: /data.svc/Territories[99999]/Employees. It's a collection of employees, scoped to a particular territory. There's a many-to-many relationship between territories and employees (at least according to the whitepaper). If I want to associate an existing employee with territory 99999, I POST a representation of the employee to the scoped entity-set. (The representation just contains the employee's database ID.) A new resource is created at a URI like /data.svc/Territories[99999]/Employees[3]: it's the relationship between territory 99999 and employee 3.

Representations

"Currently Astoria can represent data in plain XML, JSON (JavaScript Object Notation) and in a subset of RDF+XML." Representations are selected through content negotiation or through a query string parameter.

Incoming representations have the same format as outgoing representations.

Links

So far, so good. But now Astoria must truly pass through the RESTful crucible. How well does it use hypermedia? Pretty well, actually. The "site map" resource links to all the top-level entity-sets. Entity-sets link to entities and to appropriate entity-sets scoped to each entity. A sample XML representation of http://myserver/data.svc/Customers gives the URI to each customer in the list, and an "orders" link to each customer's orders. This is excellent, much better than ActiveResource.

This lame diagram shows my interpretation of how Astoria resources link to each other. There are two minor missing pieces. First, there's no way to get to a virtual entity-set without constructing the URI manually. This is understandable because those URIs can be about as complicated as SQL expressions. You can't design an HTML 4 form that can generate all of them. You could support a simplified version with a HTML 5 or WADL form. I'm also thinking of a series of resources that work like Bugzilla's advanced query builder to support every kind of query building. It might not be worth it.

Second, I get the impression that a scoped entity-set links to the entities inside the set, but not to the corresponding association resources. That would mean if you want to DELETE an association, you need to construct the URI yourself. This is a guess because I didn't see a representation of a scoped collection.

Miscellaneous

As with Yahoo!'s web services, Astoria's JSON representations can be wrapped in a callback function that calls your code. This lets you use the Javascript on Demand hack described in chapter 11, to run code from a foreign web service in your Ajax application. (The "using" white paper calls this JSONP, for JSON with Padding.)

The "overview" whitepaper says the pagination variables are skip and take, but the "using" whitepaper says they're skip and top. Whitepaper bug!

You can create "service operations", which are arbitrary .NET methods exposed through GET requests. The example given is a custom query, but in practice this feature will encourage a REST-RPC style of programming. However, "[i]n the future attributes will be extended so that the specific HTTP method can be controlled." And the hooks for error checking and triggers are exposed in a way I think will promote RESTful design.

Sam's favorite section: what about caching and ETags? "Astoria services also leverage other aspects such as the well-established HTTP caching infrastructure. Data services can be configured to set various caching-related HTTP headers to cache at the web server, client agent, or intermediate agents such as proxies." It sounds like caching works automatically--with a tie-in to the database engine? No mention of ETags in either white paper.

"Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document." I sure hope not.

Verdict

Astoria services are in fact RESTful and resource-oriented. They're very similar to APP services, though not so much that the APP is obviously a better base. The main thing I'd worry about is the tendency for programmers to use the hooks for writing RPC-style code. I'd head this off at the pass with the promised support for service operations triggered by other HTTP methods, some RESTful examples, and maybe a bit of theory. But I don't know the best way to herd Microsoft programmers.

Fri Jun 01 2007 21:46 Mushroom Wellington: When we went to England we had a great lunch in Cambridge at a place called Rainbow Cafe. The highlight of my meal was a "champignon torsade", a puff pastry twist with mushrooms. Today one of Sumana's coworkers came over and I made a similar dish for dinner. It turned out incredibly well so I'll give you a recipe.

First I took the puff pastry out to thaw and made the filling. This starts with crimini mushrooms, chopped up and sauteed. Add some salt, pepper, and thyme. Then you chop up some asparagus stalks and steam them.

To those two add a cheese sauce. I made a roux with about a tablespoon each of butter and flour, then added a quarter-cup of milk and stirred in about three ounces of blue cheese.

By this time the puff pastry was thawed. My pastry was folded into fourths so it was natural to turn each fourth into a Wellington. I cut the pastry into fourths and brushed around the edges of each with egg wash. I stuck filling in the middle and folded the pastry over to make a Wellington/burrito shape. 20 minutes at 400 degrees gives delicious mushroom-asparagus pastries.

We ate these with a salad assembled from the farmer's market, and dessert was strawberries from same.

(2) Sat Jun 02 2007 00:06: Lately Project Gutenberg has been publishing a lot of science fiction. "How can this be?" you ask. "Surely science fiction was invented after 1923, the date beyond which there are only shady Internet rumors that someone might have written something at some point?" Well, yes, that's true, but a few post-1923 SF stories have slipped through the cracks due to the now-obsolete requirement that people do a little work to maintain their indefinite copyrights. So you've got some Doc Smith (unfortunately, Gutenberg author links are extremely unstable, so in a few weeks that link will probably point to Adam Smith) and so on. But today I found a Retief story on Project Gutenberg! Thus, the point of this rambling entry. Our distant descendants will know that science fiction was published as late as 1961!

(3) Sun Jun 03 2007 23:14: Wrote about 8000 words today, which is a huge amount except it wasn't fiction. It was entries for an upcoming pseudo-weblog project for which I want to have a big backlog. The writing work is pretty exhausting and I'm only about 15% done (the pseudo-weblog will run for almost a year). I'd rather get most of it over with up front than have to scramble later on and introduce delays.

(12) Mon Jun 04 2007 19:25 It's Just A Hypermedia Format: There's a children's book about marijuana called "It's Just a Plant". The title always sounded disingenuous to me because if marijuana had no interesting features apart from plantness, nobody would write a book about it. Maybe the lesson of the book is along the lines of: "It's a very special plant, a plant that Mommy and Daddy smoke to get high, but it's not ontologically disjunct from other plants."

In that spirit, here is my defence of WADL, called "It's Just a Hypermedia Format". Sometimes people say they'd like to do strange things with WADL, things I don't approve of and things they wouldn't think of doing with HTML. But WADL is just a hypermedia format. I like WADL because it's a better hypermedia format than HTML or plain XML.

WADL is a way of describing the infinite variety of HTTP requests a client might make in the future. WADL also helps the client figure out which of those infinitely many requests they actually want to make next. One term for this is "service description". Another is "hypermedia". When I say "hypermedia" I just mean links and forms, like you have in HTML.

I'm going to talk about several common objections to WADL, and then put a new objection into circulation which I think is better. A lot of this has been said already, back and forth, but I wanted to gather a bunch of thoughts into one place. I'm taking most of these these from entries in the weblogs of Mark Baker, Aristotle Pagaltzis, Dare Obasanjo, John Heintz, and Patrick Meuller, but also from general murmuring I've heard on the web.

Disclaimer: despite the fact that I wrote a frickin' book about this stuff, I don't think of myself as a "REST expert" and I don't have anything in particular invested in WADL. I just like it as a hypermedia format.

WADL encourages/requires/represents the RPC style.

I'm putting this one first because I think something like this underlies many of the ideas that some standard part of HTTP is what you really want instead of WADL. We all take it for granted that you should rarely if ever need to expose an RPC-style interface through HTTP. It follows that if I fall into the RPC style, I'm probably not using HTTP correctly.

So, here's some WADL for your delectation, a partial description of a service that supports the Atom Publishing Protocol. It's from RWS but it's very similar to stuff in section A.2 of the WADL standard.

  <resource id="atom_collection" path="{feedID}">
    <resource href="#member" />
    <method href="#getCollection" />
    <method href="#postNewAtomMember" />
  </resource>
...
  <method name="POST" id="postNewAtomMember">
    <request>
      <representation href="#entry" />
    </request>
  </method>

You might look at that and think "They've taken a RESTful POST and renamed it 'postNewAtomMember'! Those RPC bastards!" Except "postNewAtomMember" isn't the name; it's the unique ID. The name is still "POST". An HTML form can have an ID, and so can a WADL method. The ID is optional, and its job is to distinguish this POST method from other POST methods so you can reference it from elsewhere. Same as with HTML forms. That "RPC-style" method (once you multiply out the reference to #entry) has the same meaning as this HTML form:

<form action="post" id="postNewAtomMember" 
      enctype="application/atom.entry+xml">
</form>

OK, I'm not naive. I know that lots of people are going to want to make tools that take that WADL file and generate something ugly like an AtomService class which defines a method postNewAtomMember. When they should be doing something non-ugly like defining a "resource" object or class which responds to post.

But the solution is to educate people about REST so they don't make bad tools (and bad services). There's nothing here that's not in HTML forms.

The uniform interface is good enough.

If the uniform interface was good enough, we'd have no hypermedia. The uniform interface restricts the methods you might apply to a resource. It doesn't tell you which methods are applicable to a specific resource, what the representation to a POST or PUT request should look like, which resource the client wants, or how to get from one resource to another. We use hypermedia for that.

There is an HTTP method called OPTIONS, which is supposed to advertise the capabilities of a resource. The first problem is that nobody uses OPTIONS. The second problem is that the only defined behavior for OPTIONS is to say which methods of the uniform interface are supported (in the Allow header). I'd like to try a system where sending OPTIONS to a URI gets you a hypermedia description of that resource, and see where that goes.

(The uniform interface plus) Media types are good enough.

They're usually not good enough to describe the representation for a POST or PUT request. Think about HTML forms. Specifying the enctype as application/form-encoded doesn't save you from having to define the form fields. The client needs some way of mapping its internal state onto the media format the server expects. This can be described in English text, or it can be described in hypermedia, like WADL.

If there's a custom media type for the specific XML vocabulary you're using, the media type might be good enough. The catch is that your XML vocabulary must also be usable as a hypermedia format. Atom is a good hypermedia format because it's got the atom:link element. atom:link has attributes like "rel" and "type" that let the server add semantic meaning to a link for a client to pick up on. But if you need to specify a hypermedia form (see below) instead of just a link, you'll need to interpolate some WADL or XHTML into the Atom file.

You can't get away from hypermedia. Neither the uniform interface nor media types help you describe the levers of state or connect resources to each other.

Links are good enough.

Links certainly are good, which is why as a hypermedia format WADL describes them. If the XML vocabulary you're serving isn't a very good hypermedia format, if your "links" are just URIs stuck somewhere in an XML document, a WADL addendum can explain what the URIs are pointing to and what they mean. WADL links have useful semantic attributes like rel.

But links are not good enough. They're not good enough for the WWW. Lots of RESTful, resource-oriented websites make their clients do things other than follow links. If links were good enough, Google would look like this:

Hypermedia consists of links and forms. XHTML is one way of expressing forms, and WADL is another. AFAIK they are the only two XML vocabularies that can describe hypermedia forms. [Update: I forgot XForms, OpenSearch, RDF Forms, and Poland.]

There are two kinds of forms: forms for manipulating application state (where the action is GET) and forms for manipulating resource state (where the action is POST, PUT, or DELETE).

An application form helps the client figure out the next URI it should GET. This is how a search engine form works. There are a set of data structures that need to be filled in ("q should be a string") and a set of rules for turning that data into a URI (http://www.google.com/search?q=jellyfish). WADL does the same thing, with some additional features like URI templates.

The client is not making assumptions about the URI space. It's calling in structured promises that the server made earlier, possibly in the response to the previous GET. These promises were represented in hypermedia, in WADL as they are in HTML. If HTML 5 was out and had URI Templates, the hypermedia could always be HTML, but right now there are cases where it has to be WADL.

A resource form helps the client figure out how to format the representation it sends along with POST or PUT to a particular resource. This includes the media type (eg. application/form-encoded) as well as a description of what the document should look like, possibly with reference to some XML schema. Lots of people (inc. me) hate XSD, but that's how you describe what an XML document should look like.

RFC2616 is enough.

It's not enough for the WWW. We also have a hypermedia standard: HTML. HTML is not just another media format like PNG. Media formats convey state. Hypermedia formats convey the levers of state. They show the client how to turn its internal desires ("I want the next item", "I want to spawn a subordinate resource with properties x,y,z") into a next request whose URI and representation the server will understand.

Okay, RFC2616+HTML is enough.

Maybe. I haven't heard anyone say this, but I've thought it. If you grant the HTML5 improvements and URI Templates, HTML is good enough for a large number of real-world services.

I know this because in chapters 5 and 6 of RWS I designed a fairly complicated web service that was completely described in machine-readable ways, and I didn't need a line of WADL to do it. Somebody else could write WADL for that service, just as someone else can write their own link-filled HTML guide to crummy.com, but I didn't need any WADL because I chose a different hypermedia format: HTML.

HTML is missing some of WADL's nice features, but if people start serving HTML representations instead of XML representations, then WADL might die out.

It's better to program directly to the HTTP client library.

A properly written (ie. not sneakily RPC) WADL library is an HTTP client library. My Ruby WADL library is pretty lame, but it's an HTTP library. The methods that trigger HTTP requests are get, post, put, and delete. It doesn't look like most other HTTP libraries, because its metaphors are resources and representations and links, where most existing libraries are based on the request/response cycle. But it's not hiding HTTP under something else, any more than Restlet's client library is.

WADL files are monolithic, like WSDL files.

I haven't heard anyone say this explicitly, but it's a reasonable complaint, and it's one of the things that worries me. That's why in RWS I proposed WADL "snippets" that describe a resource's behavior under the uniform interface. These snippets would be interspersed in an XML representation, the way links and forms are interspersed in an HTML representation.

Monolithic "site map" hypermedia files are a problem because they tend to be cached a long time and treated as unchanging. When hypermedia snippets are served along with representations, a client will hear about any changes in the hypermedia description of a resource. It will also hear about any changes in the relationships between one resource and others. A client can automatically adapt to some changes, assuming the semantic cues stay constant. But when the client does all its work off of an old WADL file which contains all hypermedia for the service, it won't know if the WADL file changes.

To sum up, I'd like to respond to something Aristotle wrote:

So this is how you describe a REST service: you explain the type of response body your server will send, where to find links in it, and what sort of semantics and verbs a particular link implies about the resource it points to.

This is exactly what WADL is for. You can describe a RESTful service in English text so that a human being can write a custom (and probably procedural) client. Or you can describe it in hypermedia so that a client library can present it in terms of the resources you were thinking about when you designed it. Right now your options for rich hypermedia are HTML and WADL.

(1) Mon Jun 04 2007 23:10 "A crumb": Holly's constructed the Cartesian product of dessert components. It's breathtaking. Her big question is how complicated can a dessert get? I've always thought trifle was the most complicated ordinary dessert, though I've never actually had trifle.

Incidentally, I also like the idea that "American pancakes" are a dessert (an idea I first encountered on my 2002 London trip, where they were selling special pancake hardware at Sainsbury's). It makes me feel decadent whenever I eat them for breakfast. Though I don't really like pancakes.

(3) Tue Jun 05 2007 12:30: The Jon Udell interview is up. The picture makes me look like I'm a juvenile delinquent smoking a cigarette, but I'm just drinking a smoothie.

This one presented a bit of an audio challenge because Leonard speaks loudly and Sam speaks very softly.

It's twue, it's twue. When I'm nervous I get loud and sound like an idiot.

Tue Jun 05 2007 22:55 ☞ Dumb FISH.: I'm not sure why some of these are supposed to be funny, but they're all great: "Quaint and Curious Advertisements" of "Ye Olden Time" (Olden even at time of publication).

To be SOLD by
JOHN CROSBY,

LEMMON-TRADER, at the Sign of the Baſket of LEMMONS, at the South-End, Choice good and freſh LISBON LEMMONS, equal to any in Town for goodneſs, and as large in general as Lemmons commonly are, at Four Pounds O.T. per Hundred, and Ten Shillings per ſingle Dozen.

Dec. 19, 1768.

Also great is Steam Trek.

Wed Jun 06 2007 08:38 Casper The Friendly Brand: Tivo screenshot.

"Subscribe to our brand?"

Wed Jun 06 2007 13:47: OK, I put up pictures from our March trip to India and England. The juvenile delinquent picture comes from Cambridge. Other, cooler pictures include an awesome statue of a bull and this arty shot of Kannada writing. Plus English writing I hope to use as an illustrative graphic one day.

Thu Jun 07 2007 09:07:

L: Shot in the heart! And you're to blame! You give love... a bad name.
S: Deborahlob.
L: That is a pretty bad name.

Thu Jun 07 2007 23:01: Henry Story pledges to supplement RWS with REST-specific coverage of RDF. I'm pretty dismissive of RDF in the book, but 1) I'm still interested in it, and 2) I don't actually know anything about what will catch on.

In other news: first there was East Germany's Polyplay. Now, Russia's arcade games are revealed in your capitalist WIRED.

Video games were not bargains in the Soviet economy. "It wasn't exactly a luxury, but you couldn't afford to play every day, either," said museum co-founder Alexander Stakhanov. "More like once a week."

Fri Jun 08 2007 22:26:

Your affiliation with the above organization means you could save big on auto and home insurance.

I've never been prouder to be affiliated with the above organization.

(2) Fri Jun 08 2007 22:39 Computer Magic: Today I read a collection of Richard Brautigan. My mother told me about him when I was in high school and may have acquired me a copy of In Watermelon Sugar (I'm not sure how I got that) in college. Today I re-read IWS and enjoyed it a lot; it's got a Dwarf Fortress feel to it, with characters making statues of everyday objects and narrating their internal state. Trout Fishing in America wasn't as good, and the poetry was hit-and-miss. One hit was quite good, though: "Gee, You're So Beautiful That It's Starting To Rain". Not as good poetically is "At the California Institute of Technology", but it made me LOL, as the kids say (I believe I briefly turned into a cat).

(3) Sun Jun 10 2007 23:16 The Future: A Retrospective: I've started a new pseudo-weblog, called The Future: A Retrospective. It's based on a 1989 book of predictions about future consumer products. Every day I review another prediction and see what's happened to the people and technologies since 1989. Actually, that's what it looks like to you. In truth, most days I do absolutely nothing, and once in a while I fill in the backlog. Just like a webcomic!

I've seeded TF:AR with the first five items in the book, including the frickin' Smart House and one of my favorites, the Walking TV.

Mon Jun 11 2007 22:38 Things: Recursive islands. Iridium flares.

(1) Tue Jun 12 2007 13:40: I was planning not to write about REST on my weblog for a while, especially since all this week I'm writing about REST on the JavaRanch forum, but Jon Udell pointed me to a comment by Paul H. on Jon's weblog that throws down the REST gauntlet. The context is our assertion in RWS that web applications and web services should work on the same principles. I'm just going to quote the general flow of the comment:

[T]he authors' goal is stated as being one "to reunite the programmable web with the human web" ... The unstated assertion here then is that in order to meet the authors' stated goals, the majority of today's Web Applications will need to be re-architected and re-written in order to conform to a RESTful style! ... [T]he RESTful approach is essentially unproven outside of the read-only Web... doesn't this run counter to the often-voiced argument that REST builds upon what makes the web what it is today?

First off I want to say that my goal of uniting the programmable web with the human web is the lofty, inspirational kind of goal, not the kind that gets a budget and a schedule. "Dream" might have been a better word. But yes, it goes both ways: web applications should be more RESTful, and web services should be more weblike.

Now, on to the critique of web services vs. the web. My quick answer comes from Sam's and my InfoQ interview. Again, I'm just quoting the general flow:

InfoQ: Another argument often brought up is that the standard claim that REST's advantages have been proven by the Web's success is actually a wrong conclusion — the reason being that most of the Web's usage is actually non-RESTful.

LR: There's some truth to this. Earlier I said that most websites don't expose write operations RESTfully. But I think removing the non-RESTful parts of the Web would make the Web better, and wouldn't hurt its success—except in the same second-order way it would hurt the Web's success if web browsers were stricter about invalid HTML... I decided there were three important reasons [for the Web's success]: everything has an address, pages link to each other, and you can manipulate the web using only a web browser.

The first two correspond to important features of RESTful web services: addressability of resources by URI, and hypermedia-as-engine-of-application-state... Rather than promoting REST by pointing to the Web as a whole, I would point to the incredible usefulness of URIs and links, two features largely ignored by WS-*.

Longer answer. First, by number of requests the read-only web is most of the web. Even if REST only made sense for read-only web services, the success of the read-only web and the tools built around it would justify a (short) book.

Second, the read-only web is not just GET. It's also URIs, media types, links, and application forms. That's most of the web technologies, and they're used on the web as they are in RESTful web services. All that's missing are write operations and resource forms. Fittingly, there's significantly more controversy about these: see GET/POST vs. GET/POST/PUT/DELETE and do-we-need-WADL. In the interview I ask whether "architectures consciously designed with REST in mind will 'win' over architectures that are simple but only intermittently RESTful." Those other architectures are today's web application architectures.

How big is the gap between web applications and RESTful services? Well, here's a RESTful rule for web applications: POST to the same URI you GET. The URI designates an object, not an operation, and we have a special way of distinguishing between safe (GET) and unsafe (POST) operations on objects.

I don't think that all web applications should be rewritten to follow this rule, because in general I'm opposed to doing work. But when I write web applications in the future I'm certainly going to hew to that rule. It's a cleaner design. Even if you think that rule is a waste of time, you probably don't think following it will break the web—and following it makes a web application resource-oriented and RESTful.

It's true that the success of the web doesn't reflect success on every aspect of RESTful web services, but the overlap is pretty large, and the web's success certainly doesn't stem from any systematic repudiation of RESTful principles.

Tue Jun 12 2007 21:04 The Other Unicode Eye Chart: When I saw Joey Hess's Unicode Eye Chart I was bemused and charmed by this plucky Unicode eye chart. I also thought back to the days of my youth, when for quite some time I was able to deny the optometrist his due by memorizing the eye chart while the optometrist was talking to my mother or something. Eventually I was found out and I got glasses. But it would have been tricker for me to get away with it if the eye chart had been constantly changing.

That's why I made The Other Unicode Eye Chart, with my patented "dynamically generated every 5 minutes" CPU load-saver. Now you can test your eyesight, your recall, and your browser's Unicode support, all at the same time. What do you think, sirs?

(4) Wed Jun 13 2007 22:36: John le Carré should write a novelization of Spy vs. Spy.

Wed Jun 13 2007 22:44: From a search request:

What did the tamale say when it reached the end of the tightrope? joke

I don't get it.

Fri Jun 15 2007 15:32: Until just a few days ago I thought that the two-handed sword so common in fantasy games was a sword with a hilt on the end of each blade, such that you could either hold each hilt to get more leverage when blocking, or swing it around like a regular sword. I never explicitly examined this idea and said "Yes, this makes sense," but it looks pretty silly now that I've ascertained that a two-handed sword is just a regular sword that's so friggin' huge you need two hands to operate it. Avoiding this kind of misunderstanding may be an advantage of newer, more graphics-intensive fantasy games.

Sun Jun 17 2007 01:56 General Purpose Writing Tip: Replace "ironically" with "interestingly".

Mon Jun 18 2007 00:18: I'm taking a little California vacation before Foo Camp. So far I've visited Ed, Manoj, Andrew & Claudia, and now I'm staying with Rachel & Jeremy. These names mean nothing to you! It is like a soup of names where the broth is your own despair!

My asteroid mining story was rejected from Strange Horizons, at the same time I finished a story for submission to Viable Paradise which I'm really happy about. This gives me the idea that I should try to get the new story published and send the rejected one in for VP.

(1) Tue Jun 19 2007 20:22: Ah, delicious Mission burritos.

A while ago I saw that someone wrote a paper/article/something called something like "The Object Model of the World Wide Web". It may have been someone's WSEC position paper. I want to rip off that title for a talk I want to give at Foo Camp, but I can't find the original to give proper credit. Does anyone else remember this?

Thu Jun 21 2007 12:38 Do You Have to Let It Prelinger?: Yesterday I went with Adam and Alexei to the Prelinger Archives, which were generally deemed awesome. I took lots of pictures (coming when I get back), which is good as I haven't found any pictures online that give a feel for the experience of finding all sorts of bizarre books and magazines. There are some that give you a feel for the library stacks, and now that I see the photos others have taken I think the world needs some close-ups of the bookshelves to convey the browsing experience.

(1) Fri Jun 22 2007 01:20 Awesome Day: Today Adam and I walked the GG Bridge, and ate at Greens, and Chez Panisse (cafe), and saw Mike Daisey do a monologue. I don't even know how all this awesome stuff happened. At first I had a superstition that this awesome day meant a very terrible day was in my future. Then I decided that it was actually meant to cancel out some very terrible day in my past. Then I decided that kind of thinking was counterproductive, and got out the dental floss.

(2) Sat Jun 23 2007 10:12 "I'd blog that.": At Camp FOO, which is less like Camp Snoopy than I was led to believe. I give a talk at 1:00 and hopefully some people will show up. I've met many people including Lucas Carlson.

This entry is like the weird diary-like postcards my father used to write to himself.

Sat Jun 23 2007 13:43: In a presentation by Scott Berkun; he just mentioned The Ten Books on Architecture, which he calls the first pattern language book. Plus, I'm sitting next to Andy Baio. It's the same name-dropping I was doing when I was visiting friends in San Francisco, except you've got a better chance of knowing who the people are!

Sun Jun 24 2007 21:55 Water bottle siege engine: I didn't see anyone else doing this at Foo Camp, so I kept the detente, but now I can reveal the deadly secret behind the overly complicated free water bottle we were given. In the wrong hands, it becomes a catapult, capable of lobbing little balls of paper over two feet. This 2-second video smuggled out of my digital camera tells the story.

(2) Tue Jun 26 2007 00:57 I Got Hit By A Junk Car: I got email from a guy who wanted to know if he could subscribe to only my technical entries and skip the stuff about awesome dinosaurs and my boring life. Well, you can subscribe to a specific category, and although I don't use categories as much as I used to, I have been filing REST entires under "rest", which is probably what you want to subscribe to. (Here's the RSS feed.) And in fact you might want to do that now because I'm going to talk about the sensory overload experience that is Foo Camp.

The bizarre thing about Foo Camp is that you are constantly meeting interesting people. It never stops. Five minutes before Fitz and I left, we met Molly Wheeler, who works at the Beinecke Rare Book and Manuscript Library at Yale. I thought this was awesome because I love old books and manuscripts. Fitz thought it was awesome because he is a couple steps removed from a bunch of ancient manuscripts that are, for reasons too complicated to go into here, rotting in boxes.

I was afraid I would spend all my time with the few people I already knew, but that didn't happen, possibly due to huge overcompensation on my part. After a few minutes of conversation I felt my conversant was getting disturbingly close to being someone I knew, and I started feeling uncomfortable talking to them. As Robert said on the way back to San Francisco, "I think I'm going to need two or three days of not talking to anybody, just to process everything."

I had excellent conversations with people I'd really wanted to meet, like Bryan O'Sullivan, Scott Berkun, Carl Malamud (note to self: write separate entry), Teresa Nielsen Hayden (who encouraged me to make a submission to Viable Paradise, which I will do when I get home), Matt Webb (previously mentioned as holder of world's most awesome job), and Brewster Kahle.

New paragraph. I was boring Brewster about how the Internet Archive is great as a huge storage unit for individual files, and okay as a way to find individual files, but very bad when it comes to automatically processing or transforming large amounts of raw data. You have to find and download all that data, process it locally, and only then can you upload your derivative works back to the Archive. I'll have more to say about this later, but at this point in the conversation we were mercifully distracted by a junk pickup with a junk gasifier in the bed.

Someone (probably owner John Rinaldi, though he's not on the Foo Camp guest list) showed us how it worked, filled it up with walnut shells, and started burning off the hydrogen and carbon monoxide to heat up the system. After a brief run-in with security (there was no nearby fire extinguisher), probably-John-Rinaldi fired up the engine and started directing the hydrogen and carbon monoxide into it. Then he started driving around. Brewster and I and several other people crowded in and it was a lot like taking a ride in a junky 1975 GMC pickup, except with a slight odor of walnut. The driver claimed a ratio of 20 pounds of walnut shells to 1 gallon of fuel, and a price of $20/ton for walnut shells, and all those 2*10^xes give a fuel price of $0.20 a gallon. You do have to keep shovelling them in, though.

More later.

(1) Thu Jun 28 2007 07:41: Right now it seems like a Foo Camp withdrawal dream, but I have photographic proof, so I'm pretty sure it happened. Last (ie. Tuesday) night I ate dinner with John McCarthy and an astronaut. Specifically Janice Voss, whose lecture about mapping and being in space I'd listened to online. This happened because our old neighbor Susan McCarthy of Becoming a Tiger fame is John McCarthy's daughter. I also met Susan's half-brother Tim.

The highlight for me was telling John about REST, but John had apparently been talking to Janice about science fiction, and everyone at the table was a fan, so that was the dominant topic of conversation. Janice had a big list printed on pink paper with the books she's read and what she'd thought of them, a necessary measure equivalent to my Pocket Wisherman when you've read so many books that the pressing question in the bookstore is which ones you haven't read.

Janice also stole the show with her story of taking the Foundation trilogy on the Space Shuttle as a personal item and reading it by Earthlight, during a day when the mission has been completed but they can't land yet (she used a term of art for this which I immediately forgot).

I have a huge number of interesting pictures from Prelinger, Foo Camp, and a trip I took with Susan to a Pacifica tide pool. I took really high-quality pictures and now the problem is putting up download-quality pictures for you guys without having two different systems.

As an experiment I uploaded my video of playful seals to Google Video. Video quality suffered quite a bit, but you can see some seal-shaped objects frolicking around. Jake, also check out the David Thorpe-esque postcard I saw in Susan's house.

(1) Fri Jun 29 2007 16:47 Random photos: After some experimentation I've set up F-Spot to manage my photos. It generates scaled-down thumbnail galleries suitable for rsyncing to crummy.com, so hopefully that's what you'll see in the future. I've put up three galleries I created while testing.

• Rachel's March visit to New York. Surprise guest: Peter Hodgson!
• Adam and my trip to the Golden Gate bridge. Includes do-it-yourself bridge photo.
• Susan McCarthy takes me to the tide pools. Includes seals, sea urchins, and slacker fish.

Fri Jun 29 2007 18:56: Photo mania continues with pictures from our Prelinger trip. Don't miss the ephemera boxes, the candy industry trade magazine, the Jargon File, the dedication for Wake Up Alone and Like It!, and of course Pornography.

Update: The continuation itself continues with Foo Camp pictures. Witness the chaotic schedule board, the chaos to write on said board, remaindered books that nobody wanted, lightning talks, the gasifier car, etc. etc. etc. I'm tired of 1) adding comments to all these pictures, and 2) posting highlights from them, so that's all for now.

Fri Jun 29 2007 20:59: I was going to tell Ben Pollack about this, but it turns out he was involved. Giovanni Corriga is porting the RESTful Web Services examples to Squeak Smalltalk.

(3) Fri Jun 29 2007 22:01: The Transformers movie is about to come out, and it's looking like a fiasco. How did this happen? Perhaps NYCB's fake 2003 interview with producer Tom DeSanto will shed some light on the matter. Or perhaps not, since, as previously stipulated, I made the whole thing up.

NYCB: So, in a live-action context how do you plan to deal with the fact that there are effectively no humans in the Transformers universe?

TDS: Well, there are humans, but nobody cares about them. They just fix things and get into trouble. So I'm going to introduce a new human character, Humie the Human. He's someone the audience can relate to.

PS: would it be possible to program a Wii to act as a theremin?

Fri Jun 29 2007 23:21 RESTful Consulting: After finishing the Ruby Cookbook I did a tiny bit of consulting, cashing in on my alleged expertise. Not a whole lot since I was working on another book at the time. Now that that book is finished, my Viable Paradise submission is in, and the vacation/Foo Camp brouhaha is now a pleasant memory, I'm starting to feel around for REST-related consulting jobs. I don't really know much of a market there is for this stuff, but given the market for free advice I suspect there's something.

I'm also talking to a couple companies about full-time positions. I'm not going to make any decisions for at least a couple weeks, so if you have an idea for what I should do next, please email me. I'd really like to apply the stuff I learned while writing RWS, but if you want to give me a job crashing giant robots into each other I probably won't say no.

Sat Jun 30 2007 18:02 Right Ho, Jeeves: On Project Gutenberg.