What the future of RESTful API design holds for developers
RESTful APIs are slowly being regarded as superior to service-oriented architectures. But what does that mean for architects and developers? Tom Nolle offers his take.
In the world of componentized applications, the most enduring debate seems to be the one between service-oriented architecture and representational state transfer. Here we look at which comes out on top and why.
SOA has become typecast as rigid and heavyweight approaches to component connection and workflow, and REST is gaining traction. Both characterizations are simplistic, but to get started with RESTful API design, architects and developers have to understand the differences between SOA and REST, track the evolution of REST with the cloud and microservices and know how to build solid and compliant RESTful workflows.
SOA is a broad term for application design based on linked and componentized services and in that broad sense, REST is actually an implementation of SOA. The actual API competition is between the Simple Object Access Protocol (SOAP) and Web services standards used to implement it and REST. The difference between the two arises from their roots: SOAP evolved from remote-procedure-call technologies used to extend modular programming over network connections and REST from the Internet's "resource" view of components.
Stateful vs. stateless
With SOAP, networked components are modules, meaning they can be seen as "procedures" or "classes" with function calls and parameters. The goal of SOAP is to make a procedure work in remote form, including letting developers find the procedure and properly bind to it for execution. With REST, components represent a resource that you request access to -- a true black box whose implementation details are opaque. There is no presumption with SOAP that the remote components are stateless. The same can be said for a local procedure, where with REST the presumption is that all calls are stateless; nothing can be retained by the RESTful service between executions.
Cloud computing and microservices are almost certain to make RESTful APIs the rule in the future, so it's important for developers and architects to make the most of REST.
It's this stateless property that has made REST useful in cloud applications. Stateless components can be freely redeployed if something fails and scaled to accommodate load changes. This is because any request can be directed to any instance of a component; there can be nothing saved in another instance that somehow has to be "remembered" by the next transaction. It's also possible to develop in SOAP that way, but it's not required.
REST is preferred for Web use for this reason alone, but the RESTful model is also helpful in cloud services since binding to a service via an API is simply a matter of controlling the way a URL is decoded. If an application "knows" a component or microservice by a URL, changing the IP address associated with that URL will let the request be redirected to a instance if the original component instance fails. No other directory management is required. If the URL is made to point to a load balancer, then simple algorithms can distribute work because no request can expect to be handled by an instance that "remembers" the state.
The cloud and microservices
Cloud computing and microservices are almost certain to make RESTful API design the rule in the future, so it's important for developers and architects to make the most of REST. That means addressing state control consistently in your applications, managing security in cases of looser component coupling and creating effective service directories.
There are two ways to manage state in REST -- pass state to the service in the RESTful call, or have state maintained by a back-end database accessible by any instance of the service. It's critical that a consistent approach be taken if you want RESTful applications to be as compliant as SOAP-based ones would normally be. Unless access to a back-end state database is impractical, consider back-end state management as the preferred choice. Client-side state control can lead to problems if the client instance fails.
Keeping things secure
Security issues in REST can be formidable, but in most cases they're linked to a presumption that the components of an application are addressed on the open Internet or VPN. A major step in REST security can be taken simply by establishing a private RFC 1918 address space in which the components deploy. When this isn't practical because broad integration among components is essential to the application, then using secure connection like https will likely be sufficient. Identity tokens can also be made part of the RESTful API data package.
There are many REST directory services, ProgrammableWeb being perhaps the best known, but they focus on publically exposed APIs. There is some debate in the Internet community about whether private RESTful API design is an oxymoron, but as a practical matter, most companies will need to use a private API directory to offer developer access to their RESTful APIs. Otherwise, company data and compliance requirements are almost certain to be compromised.
If you're looking for RESTful API directory tools, focus on those designed to accommodate microservices, because that's the trend in cloud APIs overall. The key requirement is to support three tiers of API -- the truly private internal or even departmental APIs, the "partner" or community APIs and the public APIs. Remember, though, if a Web service or microservice is accessible within a network address space, it can be hacked. Proper address control or encryption of workflows is essential even if the API directory is secure.
REST and microservices offer easy component integration and the potential for greater scalability and resiliency in cloud and virtualized applications. While they do this in part by loosening the tight rules for component binding that SOAP , application planners and developers can augment security and compliance support in other ways. In any event, REST and microservices seem to be gaining support quickly, so it's wise to prepare to use them in your own applications.
