For over two decades, API design and architecture remained remarkably consistent. Perhaps it’s the outsized influence of Roy Fielding’s RESTful dissertation, but API designers have stuck to the principles of stateless architecture, resource-based endpoints, and HTTP commands to an impressive degree. That’s all starting to change, now that we’ve radically recontextualized the way we use APIs.

This doesn’t mean traditional API design is obsolete. REST, stable HTTP commands, and resource-based endpoints are still a staple of API architecture. However, the rapid proliferation of AI agents and the spread of APIs as a product in and of themselves are impacting the way designers and developers are creating APIs. Here are six ways that traditional API design has been evolving in the last few years.

1. API Design Now Privileges Machines Over Humans

Traditional API design was built for human users, meaning that everything from endpoints to API documentation to services needs to be usable and understandable by actual people. The rise of agentic AI is changing this design principle, as neglecting to describe the API for an agent forces it to make up its own workflow.

Traditional API design exposes assets as a series of endpoints, like /userID, /email, /orders, for example. On the other hand, Model Context Protocol (MCP) servers, which are exposed to AI agents, often bundle multiple assets or services together into a single endpoint. This is a significant departure from traditional API architecture.

2. APIs Now Cater to Multiple Consumer Types

Traditional APIs are designed with a single user in mind. That assumption is no longer a safe bet, as an API is almost as likely to be consumed by a machine as a human user. An agent might interact with various systems, ending calls from different IP addresses with different speeds, capacities, and expectations, for example.

This has all manner of implications for API design. A one-size-fits-all rate limiting solution might not be appropriate in this new configuration. A keys-to-the-kingdom authorization system might not be appropriate, either. It might even result in a discoverability gap if an API isn’t optimized for machine discovery.

3. Moving Away From Resources Toward Capabilities

Traditional API design is organized around resources, typically with endpoints named after nouns that can be interacted with using HTTP commands. Users send HTTP requests like GET, POST, PATCH, PUT, or DELETE to endpoints like /userID, /orders, or /inventory to interact with the backend. This makes APIs predictable and easily understandable without having to consult external documentation.

Agentic AI and machinic systems abandon that principle. Agents are usually trying to get something done, whether that’s booking a flight or messaging a customer. Maintaining resource-based endpoints forces agentic AI to chain multiple calls together, often forcing the AI to infer how to realize its goals unless the workflow is specified. As a result, many API designers are starting to expose business functions as endpoints. HTTP requests are still driving the system at the core, but the fundamental API architecture is starting to shift in light of recent changes.

4. API Security Is Evolving With Just-in-Time Access

Traditional API security focused almost exclusively on protecting endpoints from unauthorized users. Authentication, authorization, rate limiting, and TLS were largely designed around applications acting on behalf of humans with relatively predictable request patterns. Authentication, authorization, rate limiting, and TLS were largely designed around human users with relatively predictable usage patterns. Once a client had been authenticated and granted the appropriate scope, it was assumed they would behave in expected ways.

This approach has been shifting for years, with APIs becoming the connective tissue in microservices, cloud-native applications, third-party integrations, and, most recently, AI systems. The rise of agentic AI and machine identity has caused a spike in everything from zero-trust architecture to short-lived authentication tokens to fine-grained authorization as a response to the reality that a single agent session can last far longer than their human counterpart, potentially making a security breach far more serious. It’s one reason that 51% of developers are concerned about unauthorized or excessive API calls from AI agents.

5. API Failures Are Now System-Wide

API failure used to be restricted to a single endpoint when every resource was supposed to be self-contained. This is no longer the case. With APIs acting as the infrastructure for a vast swathe of modern tools, connecting everything from SaaS to AI ecosystems, an API outage can have significant downstream effects.

As Jennifer and Theo Klein put it in an article for USENIX, “most frontend services have many transitive dependencies, and understanding these dependencies becomes increasingly difficult as your system grows in scale and complexity.” They go on to describe some of the risks of these interconnected systems, warning that “risky dependencies typically exist in production unnoticed until one of them causes a major serving outage.” This means it’s no longer enough to make sure that an API is functioning. You should also audit your APIs for dependencies — both upstream and downstream — as well as making extra sure to update or sunset APIs properly when changes occur.

6. API Design Impacts Regulatory Compliance More Than Ever Before

When APIs were first introduced, they were mainly technical tools intended to be used by highly tech-savvy end users. A lot has changed since APIs were first adopted in the early 2000s. Not only have APIs become products in and of themselves, but they are also an official communication channel that interacts with sensitive, often regulated, data. That means they must comply with certain digital regulations, just like any other digital communication medium.

Healthcare systems must implement Fast Healthcare Interoperability Resources (FHIR) standards in their APIs, for example. Financial institutions must follow open finance regulations. API designers need to take this into consideration, making sure that consent is handled properly while ensuring that output matches certain criteria.

Final Thoughts on the Evolution of API Design

The ways we create, use, and consume APIs are going to continue to evolve. While not even a crystal ball could tell us what even the near future will bring, for at least the foreseeable future, the AI and agentic genies aren’t going back in the bottle. While microservices might be rolling back, APIs-as-a-product continue to rise. You don’t need to be a fortune teller to conclude that the days of APIs staying strictly on the backend are long gone. API design is going to continue to evolve in light of that fact.