"REST Has Become A Buzzword"

This edition of "¡APIcryphal!" summarizes the creation, rise, and subsequent interpretations of Dr. Roy T. Fielding's REST architectural style since 2000.

TL;DR: 

As REST shows us, the more successful a term becomes, the further afield it may become from the author's original intent. But does that matter? 

Occasionally, moments emerge among the daily business as usual, changing the course of entire industries. The API landscape is a space as molded by legend as any other. While their accuracy to actual events remains debated, these tales remain the cornerstones of hallway tracks and executive talking points. These are API's apocryphal stories - the ¡APIcryphal!

Observance

In Oct 1991, Sir Tim Berners-Lee created a mailing list to facilitate contributions from developers worldwide. The mailing list was called www-talk, and the project was something he called the "World Wide Web". In 1993, a doctoral student at UC Irvine named Roy T. Fielding made his first contribution to the list: "a convoluted description of MOMspider". That initial suggestion would later become HTML's META element.

Over the next several years, Fielding's contributions to the web would grow. He wrote the standards for HTTP and URI and co-founded the Apache HTTP Server project. This server work led Fielding to capture his observations about what made the web work. These observations ultimately became his doctoral dissertation: "Architectural Styles and the Design of Network-based Software Architectures", published in 2000. Within this dissertation, Fielding describes a series of constraints comprising "Representational State Transfer", or REST. 

Fielding's use of the phrase "architectural style" was quite deliberate. It was an attempt to look across many software architectures (something that could be called a vertical abstraction) and identify useful, repeatedly appearing things. These commonalities - a "horizontal abstraction" - could then be given a name. The name, or REST, was to make it easier to have a meaningful conversation and accumulate knowledge about the science behind the design. 

REST arrived at a critical point in the web's history. There were many options for exchanging data between software systems in this era: COBRA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model), and SOAP (Simple Object Access Protocol), to name a few. However, those approaches often involved a steep learning curve, proprietary protocols, and complex implementations. As the demand for APIs grew - first because of Web 2.0, or "web mashups" and then by the explosion of mobile app development throughout the aughts - software developers increasingly chose REST. This seeded the API landscape for incredible growth as the dominant API style for the 2010s. 

REST's success over other alternatives is because it encourages:

• Leveraging HTTP: Utilizing Hypertext Transfer Protocol (HTTP), developers didn't have to learn an entirely new protocol for distributed interactions.
• Simplicity: Leveraging standard HTTP methods (GET, POST, PUT, DELETE) for data access and manipulation simplified designing, developing, and understanding interactions between actors in a distributed system. 
• Interoperability: Since REST relies on HTTP, it promotes interoperability, allowing different programming languages and platforms to easily participate as long as they understand the HTTP protocol - something that had been readily included by this point.
• Statelessness: Because servers are encouraged not to store state between requests, server design is simplified, and scalability is improved. Distributing workloads across multiple servers ("horizontal scaling") becomes more manageable. 
• Flexibility: REST allows communication using a variety of data formats, including JSON and XML, catering to different developer preferences and data needs. 

The REST architectural style exhibited the "Goldilocks Principle" at precisely a critical inflection point in implementing distributed systems - just enough descriptive guidance to be useful but not so prescriptive or complex as to spurn early adopters. 

Interpretation

REST is a collection of design constraints for network-based applications. While REST wasn't explicitly about APIs, the natural alignment with an exploding area of growth across industries made the terms synonymous. 

Further, a rising number of implementations brought an increasing number of software practitioners, many of whom have their own preferences and agendas. It was a period highlighted by the tension between rapid development and interpretation purity. While the exuberance over REST, in general, was positive, the dilution of key tenants posed long-term issues with maintainability, performance, and scalability. The worst oversimplifications equated REST with "JSON over HTTP". Adding to the confusion, these variations were referred to as "RESTish" or "RESTful" API designs. 

Fielding was frequently critical of articles and authors during this time through social media and his blog. In 2007, he attempted to more succinctly characterize REST and "articulate it in a manner less susceptible to misunderstanding by the software engineering community (as opposed to the network protocols community)". This effort was later used as the basis for the style's presentation in the Taylor, Medvidovic, and Dashofy textbook on software architecture. 

He still found himself correcting misleading examples which claimed to adhere to REST's constraints:

"Please try to adhere to them or choose some other buzzword for your API" - Fielding in a 2008 Essay

In 2017, nearly 25 years after his first www-talk contribution, Fielding co-authored Reflections on the REST Architectural Style and "Principled Design of the Modern Web Architecture". His co-authors on that paper are Richard Taylor, Justin Erenkrantz, Michael Gorlick, Jim Whitehead, Rohit Khare, and Peyman Oreizy. From the paper's opening:

"REST has also become an industry buzzword: frequently abused to suit a particular argument, confused with the general notion of using HTTP, and denigrated for not being more like a programming methodology or implementation framework."

Fielding's frequent advocacy, both online and at events, inspired a small, but extremely vocal, group of fanatical purists. They treated REST's constraints as a stringent checklist of requirements to adhere to. Referring to themselves as "RESTafarians", these self-identified individuals displayed gatekeeping tendencies toward others seeking answers to common questions. 

"There can be a tendency among more zealous proponents of REST to turn any discussions about the API design into an aggressively meticulous debate about what is and is not RESTful'."

Despite being an active critic of lazy or incomplete REST depictions, Fielding seemed to recognize that attempting some performative architectural correctness was not beneficial:

"Architectural styles are named so we can easily discuss & contrast them, not so they can be carried on banners or elevated to purity." - Fielding on Twitter (2016)

Still, this faint damning of RESTafarians should not be mistaken for acceptance of a more abstract, commonly practiced version of REST. On social media, Fielding would concede that the industry would do what it will with terms and state that he was powerless to stop it. However, he also remained adamant that the popular usage and his REST definition were two very different things.

"REST has become a buzzword. There's nothing particularly wrong with that unless you happen to be me or working with me." - Fielding in a 2017 YouTube Video 

More than once, this firm - sometimes bordering on sassy - defense resulted in personal attacks by those who were ignorant of Fielding's work, thought they knew better, had poor impulse control, or some combination of all three.

Reversal

GraphQL, released by Facebook in 2015, was heralded by some as "the REST killer" or "REST 2.0". The real story is more multifaceted. The biggest contrarian to Dr. Fielding's concept of REST wasn't a single query language or alternative architecture but the very act of its widespread adoption. 

REST, the architectural style, outlines a powerful set of constraints that influence desirable properties in web applications. However, as REST, the brand, entered the mainstream, it became subjected to ongoing negotiation and reinterpretation of its meaning. This wasn't a bug, but a feature - a testament to REST's flexibility and adaptability to be applied outside of the confines of software theory.

REST means different things to different audiences. It means one thing to the developer completing their assignments in Jira, another to the engineering leader attempting to herd cats through a transformation, and yet another to the marketplace selling solutions. The term's conflation isn't an indictment of people's laxness but an example of its success.

We see this pattern repeatedly throughout the tech landscape. Agile methodologies, cloud computing, and even DevOps all started with specific principles but branched out, sometimes to their originator's chagrin, as diverse groups adopted them. Attempts to rigidly enforce a single definition often prove futile. The power of a well-communicated promise lies in its ability to inspire many interpretations and fuel innovation. 

Legacy

Dr. Roy Fielding remains a Senior Principal Scientist at Adobe, a role he's had since 2010. He performs "research and standards work related to the World Wide Web and content management" at Adobe. His career has included notable contributions to the Apache Software Foundation (ASF), including serving on the board in many capacities. Dr. Fielding has also been awarded numerous awards, including the 1999 ACM Software System Award, the OSCON 2000 Appaloosa Award for Vision, and the 2010 ICSE Most Influential Paper Award. Dr. Fielding was also among the first elected members of the W3C Technical Architecture Group and one of the first selected members of the TR100 by MIT Technology Review. 

Dr. Fielding speaks less often about REST at public events than he used to. If I were to hazard a guess, it's that he has said all he has to say about the subject. He acknowledges your freedom to debate the details or stump for your interpretation, but after literal decades, he's no longer interested in entertaining bad-faith actors; find someone else to validate your cleverness. 

From Twitter, in Dr. Fielding's own words: 

"One problem with 'mostly right' takes on my dissertation is when they see the trees but not the forest. REST isn't about APIs; it's about system interaction for network-based apps. But the constraints were also designed to induce a uniform network-based API (URI+HTTP+HTML+etc).

"Yes, REST is a buzzword, it has been abused (as expected), and the name refers to an architectural style in a dissertation about software engineering. However, seeing the Web through REST goggles does reveal the general-purpose network-based API designed within that architecture.

"So, then we have this problem of people wanting an API for their network-based application, being told they should learn from REST, and interpreting that as 'use REST' like they would use a library import. That's not how it works, and recipients eventually blame the advice. Fine.

"It doesn't really work for me to sit here and blame practitioners for not understanding how to design their own large-scale software systems using my advice, that I provided in my dissertation, since I was the one who decided that wasn't my audience at the time. Fine.

"But at what point do people realize that the reason they are paid to do their jobs, or being respected for the great jobs that they already do, is because they can use their own brains to fill in the details specific to their own system context? Learn, apply, iterate!"