How REST APIs Are Driving the Digital Industrial Revolution

Systems evolve with certain observable patterns. If the Web is looked at as a society and applications are its members, we are watching a path of progress similar to our human societal development.

English philosopher Herbert Spencer said, "The earlier (and more primitive) military society has the goal of conquest and defense, is centralised, economically self-sufficient, collectivistic, puts the good of a group over the good of an individual, uses compulsion, force and repression, and rewards loyalty, obedience and discipline.[6] The industrial society, in contrast, has a goal of production and trade, is decentralised, interconnected with other societies via economic relations, works through voluntary cooperation and individual self-restraint, treats the good of individual as of the highest value, regulates the social life via voluntary relations; and values initiative, independence and innovation."

Its interesting to read Herbert’s words while considering the previous practices of closed-system, monolithic “all or nothing” applications that managed business functions from end-to-end, hosted on a dedicated infrastructure.  Versus today’s world of API driven inter-operation, microservice de-centralization with infrastructure abstracted to be inconsequential to the application layer.

Such revolutions are fueled by a society's collective agreement on a Lingua Franca for communications, and standard protocols for trade and logistics.  For the Web, application communication via REST is driving its Industrial Revolution.

API experts and pundits will describe application programming interfaces (APIs) as the technology that allows independent software to talk to one another. But what exactly does it mean for software and systems to communicate? If such conversations are taking place, what's the nature of these conversations and under what governance? How do systems with different native tongues find common ground to converse? Thankfully RESTful API architecture and it's most common implementation (the HTTP protocol) have conspired to provide the framework that is creating a profusion of collaborating systems.

A look at history, observations of current events, listening to conversations, and reflection of our own experiences will certainly highlight how communication is the centerpiece of everything.  The spectrum of community collaboration ranges from “Isolated” to “Integrated”, depending on the lack of, or effectiveness of, communication.  Communication, in all its modes, is the product of language, grammar, and many other conversational elements.

Artificial Intelligence engineers and certain enthusiasts are pursuing replicating, in computer systems, the art of human communication.  Until this is achieved and made a commodity, the internet has shown us, and the propagation of REST APIs has decided for us, that the best approach to create universal computer communications that will power fast and easy collaborations between systems, is to dispense with complex linguistic notions and instead use a simple grammar and language to convey messages constrained to only say;“This is the state of the resource now” or “This is what I want the state of the resource to be”.

REST gives us a manageable software-to-software tool set to confidently create and interpret messaging between independent software applications in a predictable and ubiquitous way.  

REST provides the “Grammar” rules, which in summary are:

1. There will be a resource with an addressable URI; in other words a standard method for other software applications to find the resource. An example would be:

GET [base URL]/people/williamshakespeare

2. There will be the transfer of a representation of the resource. For example, if the source software application intends to have a name and address set in a target software application, transferring the end-state of that resource (name and address) via a REST-compliant command (ie: HTTP’s POST, PUT, and PATCH verbs) is the expected communication.  The target software application will set the resource to the presented state using processes of its own discretion.  An example that posts new data to the target system might be:

POST [base URL]/people/williamshakespeare
{
 "name": "William Shakespeare",
 "email": "bill@stratford-upon-avon.co.uk",
 "address": "Henley Street, Stratford-upon-Avon, Warwickshire, England"
}

3. The request to have a resource state change is done with an expression that’s compliant with the protocol agreed upon in the communication channel. For example, if HTTP is the agreed upon protocol for communication between the source and target software applications, the source and target will rely HTTP’s verbs to invoke a request for state change.

4. REST does not attempt any situational context, it is stateless.  By its explicit omission of it, it makes the inarguable assertion that situational context will not be considered in the message exchange.  If situational context is relevant to either the sender or receiver, it is up to each to manage.  This is key, in that REST makes it understood by all participants to only expect the conveyance of the current or desired state of a resource, thus the messages are idempotent. For example, suppose Bill moved:

POST [base URL]/people/williamshakespeare
{
 "name": "William Shakespeare",
 "email": "bill@stratford-upon-avon.co.uk",
 "address": "Payton Street, Stratford-upon-Avon, Warwickshire, England"
}

If the new location was not agreeable to Bill, and he decided to move back, it would be a break of the Lingua Franca to do this:

POST [base URL]/people/williamshakespeare
{
 "name": "William Shakespeare",
 "email": "bill@stratford-upon-avon.co.uk",
 "address": "previous"
}

There is no consideration of Bill’s "state" of being in a new location and moving back to a previous address, there is only the stateless communication of what his address is.  Each software application, the source and the target, is free to monitor and track Bill’s state as he moves from one place to another, but the communication channel between them remains stateless.  The return back to Bill’s previous address would be communicated in this way:

POST [base URL]/people/williamshakespeare
{
 "name": "William Shakespeare",
 "email": "bill@stratford-upon-avon.co.uk",
 "address": "Henley Street, Stratford-upon-Avon, Warwickshire, England"
}

5. REST does not demand a specific language. While REST is almost always practiced in the construct HTTP, HTTP is not required to meet the tenets of REST. For example, COAP is a protocol that’s associated with the Internet of Things that is considered to conform to the RESTful architectural style. Like HTTP, it comes with a standard set of commands (also known as verbs) baked-in.

6. REST will not instruct the receiver of a “change of state” request on how to affect the change.  REST only concerns itself with communicating of the expected state of the resource.

Facilitating universal human interaction to exchange information with the Web and all the systems connected to it,  was accomplished by the agreement that all browsers would comply with REST governance and HTTP protocol.  It was prudent to adopt this same approach for the exchange of services and functions between software applications, with the language allowed to vary as appropriate (HTTP, FTP, COAP, etc.).

The adoption of REST and HTTP for browsers and the resulting expansion of the Web proves the prolific power of standardized conversation models.  Extending this same model to software applications is speeding us to a new era in which entire communities of systems will be connected.  It will give us new internet-connected spaces of individual functions (micro services) that will develop into new Internet_of areas:  the Internet of Things, the Internet of Applications, the Internet of (fill in the blank).  

History confirms that a standard communication protocol is key in how we work together to extend our reach , build towers to new heights, and move into new phases of societal evolution.  

Welcome to the Web’s Industrial Revolution. 

Paul Dumas I rarely have a bad day.

Comments