RESTful Interface Description

The other day, a friend from Oz asked about IDL (interface definition language) for RESTful services (it turns out WSDL 2.0 has binding definitions that support all HTTP methods) and now there is this post from Phil Windley Crying Out for a RESTful Service Interface Description Language:

The only way that we’ll get to a place where Web 2.0 apps are more easily integrated is when we have a service interface description language and other metadata standards for RESTful services.

At the top of the post he links to another blog by Dave Rosenberg that says in part "To me the big opportunity of Web 2.0 development is the ability to create a better user experience based on features etc."

Following Phil's post is a comment starting with "What we need is a [...]".

Here's a suggestion - pick two services you would like to integrate, something that would result in real tangible value that you would actually use day-to-day, and try actually implementing these difficult integrations (and some are tricky) and write about the effort and the problems. That real effort with real implementation will surface the real problems that need solving. Crying out "you should do this" or "people need that" is just so much wishful theory talking.

In theory there is no difference between theory and practice. In practice there is.

The Web Is a Pipe

From The Web Is a Pipe:

Opportunity opens up when we use HTTP to connect our server infrastructure components together. If you use HTTP between your front-end web server and your back-end application server, suddenly you gain the ability to swap Apache for Lighttpd on demand without worrying about the FastCGI bits. Your application server won’t notice the difference. You can replace either Apache or Lighttpd with Pound or Pen. You can even replace them with some sort of hardware load balancer solution if that floats your boat.

Even better, when you use HTTP as the glue, you suddenly can use a whole host of tools to probe the various parts of your application. You can use curl to probe just your application server. Or even point a browser at it, assuming that you have a clear path through your firewalls and what not. And, if you’re really l33t, you can do a manual telnet and make just the request you need—with all the right headers—to simulate exactly a problematic client request.

Exactly. Using a web server as your application server means you can replace your application server with yet another web server.

HDR Coconut

big coconut
Originally uploaded by Haiku Garry.

I stumbled across this surreal photo of a coconut and was intrigued by the tag "HDR". What is "HDR" I thought? It turns out that HDR means high dynamic range. This is more than merely 32bits per color channel per pixel, it usually means capturing the full dynamic range. Most cameras can't do that, so the trick is to take three or more exposures and blend them together - called tone mapping or exposure mapping. Flickr is full of amazingly artistic photos with rich and deep colors. Many looks not quite right, almost as if they are a bit - but only a little bit - beyond current capabilities of computer graphics lighting models.
The HDR pools on Flickr have a lot of abandoned heavy iron cars from America's motor past, many photos of solitary houses, of disorderly mechanical/industrial buildings and one photo stream of an apparently abandoned castle.

Kaboodle

I found Kaboodle through a Google search alert (for 'social network shopping'), and for some reason I think the idea is really cool. It is sort of similar to Ta-Da lists from 37signals but more of a rich media list maker - wishlists, compare product data from different sites (very useful when hunting for a digital camera), assembling details on places to go for vacation (I could have used this last year...). Lots of uses come to mind.

The color scheme is orange and blue, like all good startups, but the site still looks fresh.

S3 support Virtual Hosting

This is good news - S3 supports the Host header in HTTP requests. I had been meaning to write about the security holes is storing different people's data within the same domain - as soon as two people host javascript, then 'cross site scripting' becomes possible within one host domain. This enhancement allows folks to trivially avoid that problem (assuming people want to host HTML and Javascript on S3 - not it's advertised purpose).

ACM Interview with Werner Vogels

I finally found time to read the ACM interview with Werner Vogels about Amazon and service oriented architecture (conducted by Jim Grey, no less). He talks a bit about Amazon history and a bit about how services affect development teams as well as the runtime and operational benefits.

Here's one of several 'lessons learned' that Werner recounts:

A second lesson is probably that by prohibiting direct database access by clients, you can make scaling and reliability improvements to your service state without involving your clients.

Interesting - since a database is also a service, what is the essential difference between direct 'database' access and direct 'service' access that improves the situation?

Another interesting comment:

Other lessons are related to how you access services: If you want to be able to aggregate services easily, if you want to insert advanced infrastructure techniques such as decentralized request routing or distributed request tracking, you need a single unified service-access mechanism.

Hmmm, the single unified access mechanism sounds like a protocol. I'm in the middle of building a new service and haven't been considering this - I wonder if I'm going to get in trouble. But I guess that's okay, since my business card does say Sr. Troublemaker...


Now this is the part that I like - as it involves my stuff!

About a million small and larger businesses sell on the Amazon platform. For example, if you go to one of the book pages, you will find that item is also available new or used from some of our many partners. These can be very small independent bookshops or larger retail operators that want to sell on our platform.

And onto REST...

Do we see that customers who develop applications using AWS care about REST or SOAP? Absolutely not! A small group of REST evangelists continue to use the Amazon Web Services numbers to drive that distinction, but we find that developers really just want to build their applications using the easiest toolkit they can find. They are not interested in what goes on the wire or how request URLs get constructed; they just want to build their applications.