I had a brief conversation with Dan Mosedale, of the Mozilla Messaging crew, where I stated my stance that such a replacement is non-pragmatic. He suggested something interesting: most mail access today is not via IMAP, but via the web.

That is a perspective I hadn’t considered, but it is certainly true. Most people receive email through Microsoft, Yahoo, Google, or AOL. Through the use of Ajax techniques, much of this mail is being delivered over HTTP. It is by no means a stretch to imagine IMAP being replaced by an HTTP-based protocol, given an effort to standardize the data format transmitted in the requests and responses.

Upon first seeing the spec, I immediately tweeted:

oEmbed completely ignores REST principles. GET with a Content-Type to the original resource. Benefit: a single URL per resource. C’mon!

Allow me to further explain…

To begin with, let’s dive into the specification, and take note of the things that immediately raise red flags.

An oEmbed exchange occurs between a consumer and a provider. A consumer wishes to show an embedded representation of a third party resource on their own web site, such as a photo or an embedded video. A provider implements the oEmbed API to allow consumers to fetch that representation.

Hmm… that sounds suspiciously like an HTTP GET request. Why the need to refer to this as “the oEmbed API”?!? Something suspect must be about to go down.

Configuration for oEmbed is very simple. Providers must specify one or more URL scheme and API endpoint pairs. The URL scheme describes which URLs provided by the service may have an embedded representation. The API endpoint describes where the consumer may request representations for those URLs.

Wait… what? This oEmbed thing requires two URLs to fetch different representations of the same resource? Have we not learned even the most rudimentary REST principles in the past few years? Here’s a quick lesson: a single resource can have multiple representations. One URL, multiple data formats. Once that is understood, the need for an oEmbed API endpoint drops away entirely.

Even so, let’s be pragmatic and use oEmbed, since some respectable providers have already implemented support for it. (Which begs further questions, but I’ll let that slide.) To start, we need to get the address of the API endpoint. That mechanism is not specified, so we’ll have to resort to hardcoding endpoints. XRDS could be useful here, but that introduces further complications. Besides, there is better way.

oEmbed with REST to the Rescue!

Since the URL to the original resource must be known, and an oEmbed representation is desired, the oEmbed API endpoint is completely unnecessary. Just request the oEmbed representation from the resource directly.

GET /photos/bees/2362225867/ HTTP/1.1
Host: flickr.com
Accept: application/oembed+xml


Flickr could then respond with our embed-ready resource.

HTTP/1.x 200 OK
Content-Type: application/oembed+xml
 
<oembed>
<version>1.0</version>
<type>photo</type>
<title>Bacon Lollys</title>
<author_name>bees</author_name>
<author_url>http://www.flickr.com/photos/bees/</author_url>
<cache_age>3600</cache_age>
<provider_name>Flickr</provider_name>
<provider_url>http://www.flickr.com/</provider_url>
<width>500</width>
<height>375</height>
<url>http://farm4.static.flickr.com/3040/2362225867_4a87ab8baf.jpg</url>
</oembed>


See that! There is absolutely zero requirement for the oEmbed API. All we need to do is define a couple data formats and the associated MIME types. While there is evidence of duplicative effort, the oEmbed formats look reasonable and have both XML and JSON output. I propose we define them as application/oembed+xml and application/oembed+json.

Error handling is equally trivial. If support for RESTful oEmbed is not implemented, a standard HTTP 406 Not Acceptable status code would be returned to the client. The client could then fail over to screen scraping or proprietary APIs as necessary.

I hope I’ve outlined my case against oEmbed effectively. If anyone has any questions or concerns, drop a line in the comments.

They aren’t “browsers” because they aren’t browsing the Web. In specific, the iTunes (Music) Store is not HTML.

Unless of course you are advocating an expansion of the meaning of the term.

Rather than advocating an expansion of meaning, I’d suggest that the term has been wrongly narrowly categorized. Allow me to explain…

To begin, I’ll paraphrase the first sentence of Wikipedia’s entry on Web browser:

A web browser is a software application that enables a user to display and interact with text, images, videos, music and other information located on a network.

A typical web browser (including Internet Explorer, Safari, and Firefox), relies on three primary technologies: HTTP, HTML, and URLs.

A URL is simply an address to a resource that is available on a network. When a URL is entered into a web browser, HTTP is used to allow the web browser and a web server to communicate with one another. The server sends the browser a document marked up using HTML, which the browser is able to display on screen.

What makes the web interesting is the concept of a hyperlink.

A hyperlink is a way to point to other resources on the network. For example, links to my site can be constructed with the following HTML:

<a href="http://www.backdrifter.com/">Backdrifter</a>


The browser understands that markup and displays it as a link to my weblog. If the link is clicked, the browser will load my site. The act of browsing is simply a matter of clicking a series of links, thus loading a sequence of URLs.

Unfortunately, people tend to associate hyperlinks directly with HTML, even though their use is not limited to HTML. The Architecture of the World Wide Web describes how to apply the concept of links to non-HTML data formats.

However, I suspect the bigger objection is the use of the term “browser” for applications that don’t leave the original website. This situation occurs naturally when a server only serves links that point back to itself. It’s important to realize, though, that a subset of the web is still the web.

Returning to the original definition and the architecture guidelines published by the W3C, it is my contention that the term “web browser” makes no particular restriction on the use of transport protocol or document format. It is simply an application that allows a person to display and interact with resources represented by URLs.

My Objective-C leanings lead me to use Ruby as a scripting language. Ruby has been propelled into the spotlight recently by Ruby on Rails, an incredible framework for developing web applications.

Objective-C and Ruby are both descendants of Smalltalk. All three languages are object-oriented, and have the notion of message passing as a central construct. Message passing is not found in more popular languages like C++ and Java, yet understanding it can give any developer an invaluable new perspective.

In an attempt to further my understanding of these concepts, I’ve recently been studying Smalltalk. While having been around for more than 30 years, the concepts behind the language are still considered state-of-the-art and its influence is broad. That influence extends all the way to the web, as I discovered in a recent entry by James Robertson.

Found in the comments is a link to an editorial by Dan Connolly, dated February 13, 1997. From the article:

HTTP was design as a distributed realization of the Objective C (originally Smalltalk) message passing infrastructure: the first few bytes of every HTTP message are a method name: GET or POST. Uniform Resource Locator is just the result of squeezing the term object reference through the IETF standardization process.

Recent projects have caused me to view the web as just such a distributed object system. However, I was not aware of the historical link to Objective-C and Smalltalk. Seen in that light, though, the message passing approach is remarkably consistent.

David Heinemeier Hansson, the creator of Ruby on Rails, is a true innovator in the web application frontier. His addition of Active Resource to edge Rails is the natural next step in this line of thinking. In his keynote address at RailsConf 2006, he gives a compelling presentation about the benefits of discovering a world of resources.

Message passing languages are efficient and productive for application development. Unfortunately, they have a minority stake of developer mindshare. Ruby and Rails are currently improving this situation. It may be wishful thinking, but I’d like to see these trends renew interest in Objective-C and Smalltalk as well.