In a REST world, there’s room for non-REST APIs

REST APIs are everywhere, but there are still use cases that justify a RESTless path. 

Broadcom’s OpenNSL, a recently unveiled software Platform that enables the development of applications on top of Broadcom’s StrataXGS network switches, is a good example of the fact that there’s room for non-REST APIs in a REST-dominated world. The OpenNSL platform, which is targeted at original equipment manufacturers, independent software vendors, and network operators, is composed of a set of APIs that align to Broadcom’s SDK.

Why didn’t Broadcom build OpenNSL as a REST API? A company representative explained:

“OpenNSL is not an API that is meant to run across the network. It is modeled on the Broadcom SDK API, which is a C-based API that applications directly link against. So the OpenNSL API and the application using it run on the switch itself. They allow control of the network, but do not run across the network. This is typical of control path applications, since the control path to OpenNSL/SDK traffic can be very high – too much to run across a network and React in time to learn thousands of layer 2 addresses or update a layer 3 routing table after a link flaps.”

Broadcom says that it does see RESTful APIs built on top of the control path, and cites its Open API as one such example. It also points to Facebook’s open switching system, FBOSS, which has an Apache Thrift interface.

Despite the fact that OpenNSL lends itself to a C-based API instead of a REST API, Broadcom expressed interest in an open source project that would add a REST interface to OpenNSL.“This is the exact type of thing we want to help foster and stimulate,” the company’s representative told me.

REST wins by default, but ...

The REST architecture offers many benefits, including simplicity, particularly when used over HTTP with a data interchange format as straightforward as JSON. As such, it’s not surprising that REST has largely become the default choice for new API development.

Even so, it’s not difficult to find examples of companies that aren’t taking the popular REST path. Machine Learning company H2O, for instance, recently released a Python API for its Sparkling Water predictive analytics platform for Apache Spark. Because Python is one of a number of programming languages commonly used in machine learning applications, the release of a Python API that can be installed via pip, Python’s package manager, makes a lot of sense.

The SDKs offered by Evernote, maker of popular productivity apps, rely on Apache Thrift, not HTTP, in part because its binary communications protocol offers much more efficient data transfer. Elasticsearch, a popular NoSQL data store that is built on Apache Lucene, also allows developers to use a Thrift interface instead of its default REST API over HTTP through the installation of a plugin.

Although alternative approaches are unlikely to dethrone REST, and for many good reasons, the fact that companies like Broadcom and Evernote aren't always turning to REST highlights the fact that it’s important for developers to think critically about their APIs and how they will be used before they make decisions about architecture and protocol.

Be sure to read the next API Design article: AnyPresence Launches JustAPIs API Builder