Stateless RESTful APIs with JSON payloads are here to stay, especially for CRUD operations. I don’t see them getting replaced anytime soon because they are the most atomic form of interaction with a server due to being modeled as native HTTP method + URI combinations. REST, known for its stateless nature, offers simplicity and scalability, making it the go-to choice for CRUD operations. While GraphQL is often presented as a replacement, offering more flexible and complex querying capabilities, I view it as a complement for data-driven use cases. Together, REST and GraphQL APIs have almost eliminated vendor-provided stateful business services in favor of providing more significant optionality—a good thing, in my opinion.
It’s now the consumer’s job to assemble these atomic services into integrations, orchestrations, and new single-purpose microservices for their use. The SOAP services of the past could never provide all consumers with the behavior they wanted and had scaling issues, especially when stateful. The responsibility has shifted to the client developer, resulting in repetitive work. Developers who would have been happy using out-of-the-box stateful services are impacted most by this shift.
Vendors sometimes offer utility functions in SDKs to eliminate some of the repeat work, which is helpful. Intermediaries have seen this as a business opportunity and, in many industries, have provided a business service layer similar to what vendors used to offer. This approach is also an improvement because these intermediary services are optional, giving the client multiple choices. New specifications have emerged, focusing on workflow documentation to address what HATEOAS attempted, but the jury is still out on the level of adoption they will achieve.
When building their integrations, orchestrations, and microservices, enterprises have embraced functions-as-a-service (FaaS) platforms to run these stateless services organized. I believe this is the right architectural approach. We are just beginning a new era where the focus and investment shift from merely talking about APIs to consuming them and using them to create many stateless functions. These serverless functions generally implement validation, transformation, API calls, logging, error handling, and retry logic—often while handling CRUD operations. Sometimes, they sit on either side of queues/topics and act as brokers.
Functions will become the next hot topic, and a new generation of tools will extend what Azure, GCP, and AWS Lambda have already started. Open-source technologies like KNative, OpenFaaS, and Kubeless will appeal to enterprises already embracing or considering Kubernetes to maintain a cloud-agnostic architecture. FaaS platforms allow great scalability and infrastructure utilization, making them a no-brainer for stateless API implementations.
These functions are generally single-purpose, serving a single API endpoint for a single important partner, acting like a trigger for an ETL sync job, and may not even be exposed as APIs but instead configured to listen for events from Kafka topics or services like EventBridge. Some may be packaged in SDKs to be executed on the client side. While some will try to apply RESTful interface designs to them, I believe that functions should take the form that best suits the consumption pattern. Next-generation development teams may even build their entire service using functions to offer RESTful CRUD APIs via FaaS. I’ve seen a few of these emerging, but it’s too early to tell if this will become a significant trend or remain a design choice for a few.
We built Poly to embrace this new world, specializing in a full-lifecycle platform for integrations, orchestrations, and microservices. If you’re interested in learning more, please get in touch with us at hello@polyapi.io.