The API is the Application
Posted on 20. Oct, 2008 by Ash Christopher in Software Development
“web servers can be clustered such that the architecture can be horizontally scaled with money. You can fix scaling issues by throwing hardware at it.“
The API, or Application Programming Interface, in simple terms, is a set of libraries which can be called which provide linked or shared functionality. In the past, this API was available as binaries or source code which would be compiled into, or released with (in the form of shared libraries) your program.
With the increased popularity of specialized web software, the original idea of the API has evolved (and some argue bastardized). The original, mainstream, bloated and cumbersome SOAP and XMLRPC web API technologies are out in favor of the new hotness – RESTful API’s.
RESTful API
REST, or Representational state transfer, is the style of software architecture which the word wide web was based on. Like all world wide web traffic, RESTful API’s are inherently stateless. They receive a request via a GET or POST, process it, then return a response. The next request is not affected by the previous, nor will future requests be affected by the requests processed in the past.
The great thing about the REST architecture is that it’s horizontally scalable. Assuming an infinite pipe, the web servers can be clustered such that the architecture can be horizontally scaled with money. You can fix scaling issues by throwing hardware at it.
Servers can be added to the cluster and scaled horizontally due to the RESTful nature of the HTTP protocol.
RESTful API as the Application
Although websites are still the main way users interact with internet-based applications, many web applications don’t rely on a web browser at all! An emerging trend is to allow users the ability to access remote resources via an API which provides data for any number of applications – web based or not. Twitter for example, is increasingly accessed via third-party applications such as Twhirl using their RESTful interface.
With the new popularity of web applications that don’t use browsers, I propose changing how these web applications are created. Instead of developing websites followed by the API, or even the API in tandem, why not create the API as the application in and of itself, then write the web application using the RESTful API? Lets think of the website as been just another application making use of remote resources.
By taking advantage of the nature of RESTful API’s we should in theory be able to create a system that scales horizontally. The added bonus is you won’t waste your time creating a website which may not be used by the end users in the future. Mobile and location based applications by their very nature will be using website access less and less.
Another advantage is that you maintain a clear separation of resources throughout your application. It forces developers to decouple the business layer from the display layer. Its very nature stops logic code from creeping into the display (as is the case with numerous PHP web applications).
It also provides many options and avenues when dealing with application management in startups and established businesses. By separating the display in this way, it makes it much easier to farm out display work to third party companies which can focus 100% on that task, decreasing your time to market.
At the recent DevHouseWaterloo meet-up, I proposed this plan to a group of software professionals and tech-savvy students, and they seemed to think this was an excellent way to create new internet based applications. I have been taking this approach with my latest project, and so far I am quite pleased. The biggest advantage I have found is that I can focus on the application. I know I am not a very good website designer nor do I pretend to be. I am much more interested in writing the core software and farming out the work to someone who can give the user interface the care it deserves.
What are the rest of the communities thoughts on this approach to software development? Do you have examples of other companies that take this approach? Are there any reasons not to pursue this development plan?
Bill
31. Dec, 2008
Hmmm… sounds like a reasonable way to do something simple, but how do you handle stateful applications. i.e. What happens now is different from what happened earlier based on a change that was made. A simple Request (What is the weather like in Waterloo, ON) and allowes for a simple response. If you need to process a stream of interactions (i.e. a Wizard) it sounds like you’d have to do something else other than REST to make that happen.
Ash Christopher
31. Dec, 2008
REST implies stateless data, so it wouldn’t really be useful for applications such as wizards. It could be used to populate data when interacting with a wizard.
Data that was entered on a previous screen would be presumably stored in the session somewhere, and that data may be passed to a REST resource which would return data to populate the page.