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.

The real issue at hand is the evolution of the web. APIs are available for so many social applications now and those applications are moving towards JSON as the data format. There is also a very good reason for this. Many applications are focused on keeping the user interface information in JavaScript and simple HTML. This means that any information required from the server must be returned in a usable format. If you are talking about JavaScript, the simplest format to deal with is JSON and that makes a lot of sense. Obviously, for many consumer applications, JavaScript and JSON would be on the rise because JavaScript is available everywhere.

If you focus on a single web application, you would never find a reason to really move away from JavaScript and JSON. However, technology is much bigger than a single application, and in many cases a single application will need to integrate with several other applications. This is where the conversation really gets interesting. JSON is a good format for your data, but what type of API should you support for your application? A few weeks ago, ReadWriteWeb had an excellent article on the state of the API. There was an interesting statistic on the API usage based on APIs on Programmable Web:

73% of the APis on Programmable Web use REST. SOAP is far behind but is still represented in 17% of the APIs.

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.

Some of the data format questions can be answered by other means as well. Some standards have started to appear that can help in specific areas, like activity streams for social activity data. Interestingly, the standard for activity streams includes data format standards for JSON and ATOM. The reason for supporting two data formats is to provide a standard way to process the data from client-side JavaScript as well as from server-side code like Java. You may think that Java has plenty of libraries for handling JSON, but the XML support in many languages, especially Java, is much more mature than JSON support. In the end, the choice of data format is based on the data context, who will use the data and how.

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.