browser scripting

surfing competition
© heydrienne

Finally we have a programmable persistence engine for our browsers. Thank you, Googleplex.

Here's what I want next: more scripting languages. Obvious choices being python and ruby. Whatever happened to this? Slingshot would still have a slight advantage over such a contraption, as Slingshot has some additional desktop integration features that browsers don't currently have. It also has the advantage that it's not running in an application shell designed for browsing the entire web; there's no time machine (back button).

There's also Adobe Flex/Apollo to consider, since they will also have an embedded database available. On the language front with Flex, Adobe recently made an ActionScript Virtual Machine 2 (AVM2) Overview available. How long before someone ports some languages to that VM? Especially since dynamic languages like python and ruby are a fairly natural fit to the AVM2 engine (compared to the JVM anyway), and the AVM2 engine will likely be the most widely deployed VM in the near future (it's included in Flash 9).

The one thing I've been most excited about given the rash of new client products available, is that we've finally got a new "browser war" on our hands. Competition is fantastic; it's going to be a wild next couple of years.

not doing REST

Rest Stop
© Grant Lindsay

From Mark Baker:

So if you're writing (or generating) contract/interface-level code which can't late-bind to all resources, everywhere, you're not doing REST ...

Is this "We don't need no stinkin contracts!" meme a reaction to the non-web-friendly WS-* world, what with it's overly complex and verbose schemas? Because I think there's plenty of room for some people to apply contracts to parts of the web. I certainly don't believe the entire web can be fully described using some all-encompassing schema language; but small pieces? Sure.

I guess what I don't understand, is how you are supposed to describe your services to someone without some kind of meta-data describing the service. Every 'web api' I've ever seen has human readable text describing the URIs, the data expected as input, and the data expected as output. (Admittedly, most of these 'web api's violate best practice HTTP principles somehow, but I think that's not an issue here; they could all be refactored to be be better HTTP citizens.) That human readable text is a contract; an interface. In English. Which is terrible. I'd rather have a machine readble version of that contract, so I can generate something human readable from it. And perhaps a validator. And some client stubs. Maybe some some test cases. Diagnostic tools. Etc.

What is the the alternative to describing your services? How is anyone going to write code to use these services, if they don't know where to send requests, what verbs to use, what data to send, and what kind of data to expect? Instead of Flickr producing a description of their web services like this, they're simply supposed to say "Flickr is now fully REST-enabled. Start here, and have fun!" ??

As with data modelling, I don't feel like there is a single answer to what schema or contract language be used. I'm not initially sold on WADL (seems too verbose), and certainly wouldn't use it if there was something else, better, for whatever project I was working on. The shape of the schema language isn't important, as long as it works for you.

So I guess contract-driven HTTP interfaces aren't REST. But this is an area I'm interested in; what name should I use, so I can avoid be labelled as "not doing REST" while I'm optimizing my use of the web by being a good HTTP citizen?

typing rest

The One Thing We Can't Live Without
© Ray

Count me as someone who wants some typing in the REST world, based on the arguments made in the post by Aristotle Pagaltzis last week.

We're talking about contracts here. Contracts need to be formalized, somehow. English is not the best language to use, especially since we have much more precise languages available to us.

My thoughts here are really just an extension to my thoughts on data serialization. Services are just the next level of thing that need to be meta-described.

Several folks have pointed out WADL (Web Application Description Language) as a potential answer, but it has at least one hole: it doesn't have a way of describing non-XML data used as input or output. For example, JSON. It certainly is simpler and more direct than WSDL, so it does have that going for it.

All in all, good thoughts all around, but we have more work to do, more proof to provide. And by more work, I don't mean getting a handful of experts in a smoky back room mandating what the formats are going to be. In fact, I'm not so sure we need a single 'format'. If you've creating some kind of machine-readable schema to describe your data and your services, you're way ahead of the game.

In any case, don't wait for WADL to be finshed before starting to build out schema for your services. Use WADL if you can, use something else (hopefully simpler) if it's more appropriate for you.

Additional thoughts on Aristotle's post from Tim Bray, Stefan Tilkov and Mike Herrick.