From REST to Agentic APIs: The Future of Backend Architecture
Traditional REST APIs are hitting limits. Explore how agentic APIs combine LLM reasoning with structured endpoints to create self-directed, context-aware backend services.
REST has been the lingua franca of backends for two decades, and it's not going away. But it was designed for a world where the client knew exactly which endpoint to call and exactly what parameters to send. Agentic clients — including LLMs — don't behave that way.
An agentic API exposes capabilities, not just endpoints. Instead of 'POST /orders/{id}/refund', I expose a 'refund_order' tool with a typed input schema and a natural-language description. The LLM picks the right tool from a catalog, and a thin server-side layer translates the tool call into the underlying REST or database operation.
This sounds like RPC with extra steps, and at the wire level it kind of is. The difference is the contract: descriptions, examples, and constraints become first-class, because they're how the agent decides what to call. Documentation stops being something you write last; it's the API.
The hard parts are authorization and idempotency. An agent that can call any tool will eventually call the wrong one, twice. Every agentic endpoint I ship now requires an idempotency key, a per-tool permission scope, and a dry-run mode the agent must use before any destructive action.
I don't think REST is dead. I think we're growing a second skin on top of it — a capability layer designed for clients that reason instead of clients that just dispatch — and that's where backend architecture is heading next.
