Yet Another Buzzword

In this day and age, “buzzwords” have been developed for almost everything. Since the web is full of information available to everyone pretty much everywhere, these terms are often picked up within relevant communities and greatly hyped.

The software engineering community is, of course, no exception.

In a previous post – “Software Defined Storage – What Is It?” from Wai Lam, our CTO here at Cirrus Data – we discussed the buzzword “SDS” which has quickly gained popularity in the enterprise storage community. Today’s buzzword is even more widely used, and most active software developers have at least heard of – the “RESTful API.”

REST API appears in software products in all different categories. From gigantic web applications like Twitter and e-commerce platforms like eBay, to WiFi-connected light bulbs and kitchen appliances, they all provide REST API. Many vendors even use REST API as an advertising plug. Given the euphoric enthusiasm it generates, one may be curious to ask, what is REST API anyway?

Well, REST API stands for “Representational State Transfer APIs.”

Thank you very much. That explains everything! But, what is REST API really?

In reality, REST API is an application programming interface that allows access to an underlying resource over the network, through the web server – no more, and no less. REST is an architectural style that provides standardized constraints on how these interfaces should be structured, such as naming conventions, authentication (stateless), etc.

The key word here is “constraints,” which means limits, which means you have to live within the agreed restrictions.

This architectural style sets compliance guidelines for APIs provided by different parties, but REST API itself is hardly a new technology or invention. It’s similar to the use of standard HTTP verbs, or naming the end-points (URL) with nouns only. These constraints make integration between different products more straightforward and efficient.

The web interface has been with us for a long time, and everyone that has ever accessed the Internet via a browser has communicated through the web interface. This is the same mechanism used by all these REST APIs. An HTTP request is sent and data is returned. Whether it is raw data or markup that a browser renders makes no difference in terms of technology. So why is REST API all of a sudden the talk of the town?

The main reason is because of – no surprise – the surge in popularity of the web, web browsers, and the Internet in general. The only reason why your WiFi-enabled light bulb can provide a REST API is because it is now connected to the Internet. Likewise, you can now access a data storage system via REST API mostly because it now also provides a browser-based user interface as opposed to a traditional command-line or desktop-based UI that communicates through closed proprietary network protocols.

REST API is just an interface. It’s a good interface standard/convention indeed, and it provides exactly what a programming interface does – it allows a product to be integrated programmatically, especially through the web, when appropriate and applicable.

One might consider this before asking questions like “does this product use REST API?” or asking in a job interview about whether or not “all the modules of your product talk via REST API?” as if REST API is some futuristic marvel of software that can be applied anywhere in any context – It’s not, and it can’t.

“Using” REST API, whether as a consumer or provider, does not automatically make a product “ready for the future.” Rather, when it is applicable, it helps make a product more capable of interacting programmatically with other products or utilities.

Indeed, the availability of a set of REST APIs is beneficial as a product feature since it facilitates easy integration with external parties. But as you have probably realized by now, REST APIs do not necessarily make a product great. A great product that provides a good user interface naturally provides REST API.

There are certain areas, purposes and functions where users and other developers can benefit from connections into third-party applications, such as with report generation and system monitoring/alerts. In these instances, providing user-facing API that is REST-style compliant is highly desirable. Yet for many inter module communications that are internal only, a set of strict REST-compliant API does not necessarily provide any additional value to the product over any other well designed and defined inter-module communication protocol.

Here at CDS, we do not pad the spec sheet with “REST API” to be fashionable. The GUI for our entire product line is built on the REST API, and the same set of REST API is readily accessible for developers.

In short, REST API provides value in the places where it actually makes sense, and not because it is technologically chic.

An alternate version of this post appeared simultaneously in App Developer Magazine.