Original text:/rest-turns-25/
original question：REST APIs Turn 25: How They Came To Be and What Could Be Next
By Shrijith Venkatramana
Translated by cat under pea flower&ChatGPT
The fundamental question: How will the emerging "AI era" affect the products of the "Web era"?
In 2000, Roy Fielding formally introduced the concept of Representational State Transfer (REST) in his doctoral dissertation. As the year 2024 draws to a close, the concept of REST will be at least 25 years old. I'll go into more detail later about how these 25 years of REST have come to characterize the "age of the Web".
With the emergence of the "ChatGPT demo" phenomenon, and the new optimism brought about by AI and automation, I'd like to take a fresh look at the history of APIs, especially RESTful APIs. I'll end this post with some wild guesses about the future of the API space in the "Age of AI".
I'm interested in history because it shows us the way forward
As a reminder to readers, Fielding's paper was written before "REST APIs" became commonplace around the world, and Fielding only refers to REST as one of the architectural styles (more like extensions to HTTP) for building "distributed hypermedia" over HTTP. REST was only used by Fielding as one of the architectural styles for building "distributed hypermedia" over HTTP (more like an extension to HTTP). As a result, his presentation of the topic is quite abstract and subtle.
In this article, rather than rehashing Fielding's ideas in detail, I'll focus on reviewing the evolution of APIs before and after the introduction of REST in order to get a clearer picture of the evolution of APIs by comparison. I'll focus more on the practical evolution of APIs than on the academic theories behind them.
Why study history? Because it helps to gain a clearer understanding of APIs and where they might evolve in the future. This article is more of a personal exploration of the topic than a rigorous academic study.
At the heart of REST: describing the needs of the "Web Age".
As Fielding began to work on his dissertation:
- The Web has been around for about 10 years.
- It has accumulated a set of standards and "modus operandi".
- Fielding tries to avoid harmful architectures by taking a deep dive into scaling, caching, component partitioning, communication, and Web evolution requirements.
- The focus is on collecting a set of Architectural Constraints to build an Architectural Style.
- The results of Fielding's research are directly applicable to improvements in HTTP and URL standards.
- As an architectural pattern, REST considers several attributes, including scalability of component interactions, common interfaces, independent deployment of components, latency, security, and backward compatibility.
A quick overview of the API history
1951 - Earliest API, but not explicitly called (Maurice Wilkes)
In 1951, Maurice Wilkes introduced the earliest API-like concept in Electronic Digital Computer Programming, proposing reusable software routines to simplify the programming of EDSAC computers.
1968 - First mention of the term "API" (Ira W. Cotton)
The term "API" was first used in 1968 in Ira W. Cotton's paper "Data Structures and Techniques for Remote Computer Graphics" to refer to an interface for remote graphics processing.
1974 - First database API (C. J. Date)
In 1974, C. J. Date contrasted the two models of relational and network databases, focusing on the differences in their program programming interfaces (APIs) to facilitate database interaction.
1991 - CORBA standard (Object Management Group)
In 1991, the Object Management Group (OMG) introduced the CORBA (Common Object Request Broker Architecture) standard, which was designed to enable communication of distributed heterogeneous applications between different systems and platforms.
1993 - CGI（Roy McCool）
In 1993, Roy McCool developed the Common Gateway Interface (CGI), an early standard for Web servers to interact with external applications, which laid the foundation for modern Web APIs.
2000 - Roy Fielding introduces the REST concept
In 2000, Roy Fielding's doctoral dissertation introduced the concept of REST (Representational State Transfer), defining a scalable stateless architecture for Web-based applications.
2002 - Bezos' API Directive: Driving Microservices
In 2002, Jeff Bezos issued a directive within Amazon requiring all teams to expose data and functionality through service interfaces (APIs), which set the stage for Amazon's adoption of microservices architecture and modern cloud computing.
2010 - Flickr's Photo API
In 2010, Flickr's Photo API allowed developers to programmatically access and manipulate user-uploaded photos, enabling features such as photo search, uploading, tagging, and metadata retrieval.
2015 - GraphQL（Meta Platforms）
In 2015, Meta Platforms (formerly Facebook) introduced GraphQL, a flexible API query language and runtime that allows clients to request only the data they need to optimize data retrieval and improve efficiency.
2016 - gRPC（Google）
In 2016, Google introduced gRPC, a high-performance, open-source Remote Procedure Call (RPC) framework that supports efficient communication between distributed systems, leveraging HTTP/2 and Protocol Buffers for data serialization.
speculation
With the Rise of AI: Standards Need to Accommodate Both Humans and AI
The standards of the "Web era" are primarily concerned with serving human users. Scalability, caching, security, comprehensibility and simplicity are all things we humans care about. These are the things that matter to us.
And now, there is a new "member" of the producer and the consumer - AI - and in many organizations, there will be teams of robots performing a variety of tasks. The ecosystem of the future will have to adapt to increase both AI and human productivity.
APIs need to be more discoverable and usable by AI intelligences: HATEOAS could be back in the limelight
Fielding's paper proposes the concept of HATEOAS (Hypermedia Engine for Application State), and he wants to emphasize the importance of API discoverability. For example, the response to an API should contain links or references to other resources available to the consumer.
This idea has not been widely popularized, but with the involvement of AI intelligences, the concept may become more important, as many AIs may use these APIs, which also means that "dynamic responses" can be generated for the needs of a particular AI.
Writing great API documentation will be easier and less expensive!
In the future, I believe the challenges of designing, testing and sharing APIs can be easily solved with advanced AI tools.
- Writing documentation is a task that requires a lot of skill, time and effort.
- Keeping code and documentation synchronized is an often-overlooked burden.
- Keeping documentation friendly, useful and supporting discoverability is a rare skill.
All of these API-related problems can be solved through the comprehension capabilities of the Large Language Model (LLM). For example, Hexmos is developing theLiveAPIWe've had good results in translating any code base into friendly and useful documentation pages with minimal human intervention. We're just getting started in this area, so I see great potential for improvement in the future.
New APIs will be rolled out significantly faster
As LLM-assisted IDEs become more popular, it's safe to assume that developing new code and features will be required:
- Less manpower
- Less time
This means that each Realization Plan can be accelerated significantly, resulting in faster development.
Even design and marketing have become less cumbersome, resulting in faster time-to-market for software products, especially APIs.
This means one thing: more experimentation, more innovation, and therefore more trial-ready APIs on the market.
Client and server code self-upgrading: more resilient systems
Few APIs can go a year without failing. Over time, the likelihood that an API will remain stable decreases dramatically. Even organizations like AWS often experience API outages that cause problems.
The root of the problem is the natural cycle of development: interfaces change, versions don't match, features are removed or added, communication is sporadic, and other factors.
There is often a lengthy negotiation process between producers and consumers to build a new consensus. With automated discovery and refactoring of code bases, the amount of "negotiation" required to "fix" these mismatches may be significantly reduced.
A New AI Economy is Forming: Forming "Teams of Intelligentsia" to Maintain New Infrastructure
While AI is not yet fully up to the task of independently developing complex software, especially end-to-end, it is conceivable that AI teams could help engineers maintain new infrastructure and APIs. they can understand customer messages, coordinate and resolve issues, and even fix patches, upgrade systems, and more.
New types of bot functionality for designing, implementing, testing, and sharing APIs are likely to emerge, and I predict a bot economy will develop in this area.
Software Becomes Cheaper: Most API Prices Will Fall
As mentioned above, the "supply side" of software is likely to outstrip the "demand side" as a lot of automation is realized. You and I both know what this means: automation and productivity gains in software development and maintenance will lead to ubiquitous software, and oversupply will inevitably lead to lower prices. Of course, there may be new APIs driven by more complex systems that may cost more than ever before, but overall, most prices are likely to go down.
Context-aware APIs on the horizon: APIs can "learn" about user needs to tailor responses
Currently, the "inputs" and "outputs" of APIs tend to be static, and can usually only handle a small number of strings and numeric fragments with specific meanings. However, the future of API input will be more complex. User preferences, needs, and specific situations may become more important "inputs" to APIs. "Me and my context" may influence an API more significantly than any other characteristic, and this trend is already underway in areas such as recommendation algorithms, which have been costly to produce and maintain. However, it is likely that such technologies will become commoditized, and some common structure for dealing with "context" may emerge.
reach a verdict
Fielding's REST theory characterized the "Web Era," and a new wave of automation is emerging as part of the "AI Era." The history of APIs shows the painful and complex path to the current state. The future will undoubtedly involve a new set of competing standards, misdirection, etc. until a new stable standard and "way of doing things" emerges.
Extended Reading
- API Design, Part I: The Age Before REST - Chelsea Troy
- Roy Fielding's REST paper was abused