Why is your RESTful API Separate From Your Website?

kinlane-productions2.s3.amazonaws.com I was having a beer with Dr. Alexandre Passant of Seevl the other day, we were talking about music, APIs and the Seevl API.

A while back I wrote a piece about Seevl titled, With Seevl Music Discovery, the Website is the API. When building the Seevl API, instead of providing a separate API to access information, Seevl relies on content negotiation principles to deliver alternative representations of web pages.

As I was talking with Passant, I kept thinking about how RESTful APIs are often deployed separately from the web site or application. Both are using HTTP, and often deliver the same information, they are just intended for two different audiences and potential uses.

This is not a new idea. Flickr delivered the Flickr API this way in the early days, and web applications like Tumblr offer their API and application side by side.

You can visit my Tumblr blog at: http://kinlane.tumblr.com/

Simple add /api/read to the same URL: http://kinlane.tumblr.com/api/read/

And you you get back an XML representation of my Tumblr blog.

Add /JSON to that URL: http://kinlane.tumblr.com/api/read/json

And you get back a JSON representation of my Tumblr blog.

In most cases, it does not makes sense for a web site or application and its RESTful API to be separated, for some reason many developers still see them as two completely separate things.

In my opinion, if the HTML, XML, and JSON representations of information are deployed side by side. And users know they can simple adjust the URL to get other formats, the type of users that hack on, embed, and redistribute information from APIs will grow beyond the developer community.