The Rise Of The API, The Future Of The Web
Last month, Twitter and Facebook made some moves to hide RSS feeds and put focus more on their APIs. There was the typical ranting that followed the news, some in favor of RSS and others not. Now that the conversation and controversy of RSS being killed again has died down, I wanted to address the real question behind Twitter’s and Facebook’s decisions. As I have said before, RSS is not dead, it is infrastructure. RSS had hoped to be adopted by the mass consumer, but the tools did not provide a truly user friendly way to consume it. That being said, a lot of tools are completely dependent upon RSS. Any news reader that aggregates information from various sites uses RSS in the background. Most, if not all, blogs will publish RSS feeds as well. So, RSS is not going anywhere except it will be continue to be in the background of a lot of applications.
Granted, this is a biased sampling because Programmable Web is focused on public web application APIs. This focus would obviously push the data in favor of web-friendly APIs like REST. This is not because one API type is better than the other, but it can be due to which API type is easier to deal with. As an API type, SOAP is fairly complicated. It was really meant to assist with the discovery of APIs and parameters, but those dynamic capabilities never proved to be as beneficial as planned. Now, the benefit of SOAP is the standard response format and the availability of libraries that can handle XML and SOAP responses. REST does not have the same restrictions on the data format, so that the response is typically custom for each API.
One important reason for the rise of APIs is that REST’s simplicity has allowed almost anyone to define an API. SOAP is complex and that complexity mean that not many people could craft a well-designed API. Thankfully, APIs are in vogue and plenty of people are writing tips for good API design. One such post caught my attention recently mainly because some of the “good” tips are not often highlighted:
- Meaningful error messages help a lot
- Providing solid API documentation reduces my need for your help, including supported operations, examples that include the request, all headers, and any response, required and optional attributes, default values, and error codes
API usage is heavily determined by how easy it is to start programming against the API. If there is no documentation available, the API will have a huge learning curve. If the documentation is sufficient, adoption of the API will definitely increase. Another reason that APIs have risen in importance is that widespread fast internet connectivity has allowed applications to pass more data around for basic browser applications and newer mobile devices require that an API exists in order to provide interactive user experiences.
A well-designed API also allows you to separate the user interface from the business logic. We have seen this type of programming shift before with client-server applications that were developed with PowerBuilder or VisualBasic, and later with the Model-View-Controller paradigm. With a good API, the server only needs to worry about business logic, data persistence and batch tasks. The user interface is then completely decoupled from the server code. This also allows various devices or applications to provide a different view of the data. As an example, you have several Twitter clients, like the web client from Twitter, TweetDeck and various mobile applications. Each user interface provides a different perspective, but they all rely on the same API to retrieve data.
As the web evolves, much of that evolution will be powered by application APIs. Some of the APIs will be application specific, like the Twitter API, and others will be more generic like the various semantic web standards. All of these available APIs allow programmers to create more interesting applications, and potentially a new API layer on top of what already exists. What this means in the long term is that we are finally getting to the point where the semantic web had hoped to be, linking data between various applications and hopefully doing something interesting.
About the Author: Rob is a software engineer, database developer, web developer, social media user, programming geek, avid reader, sports fan, data geek, and statistics geek. He does not care if something is new and shiny. He wants to know if it works, if it is better than what he uses now, and whether it makes his job or my life easier. Rob is also the author of RegularGeek.com and Founder of YackTrack.com, a social media monitoring and tracking tool.