Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

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 new 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, first 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 introduced, 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.

Next Steps

The role of RESTful APIs in B2B integration

API management tools might just bridge the gap between REST and Web services

Using APIs to unlock business value

Simplicity is key to API creation

This was last published in February 2016

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

API integration tutorial: Latest trends and strategies

Join the conversation

5 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What role has RESTful APIs played in your enterprise?
Cancel
We have implemented RESTful technology in our cloud -base application since day one.  
This make our enterprise-class run smoothly in cloud.
Cancel
While the presumption might be that REST calls are stateless, there is nothing in REST that requires them to be; and there is nothing in SOAP that encourages statefulness. I recently implemented a REST service in "go" and it is stateful.

Regarding security, there is nothing special about REST - one merely creates an authentication cookie. And BTW, if you have an authenticated session, then you are stateful.

Yes, REST is a huge improvement over SOAP - one of most absurd protocols I have ever seen in my 35+ years of programming. WSDL and SOAP are so unnecessarily complicated - like everything that comes out of W3C and OASIS. All one is trying to do is friggin' make a remote call. People were doing this in the '80s but it has been reinvented about ten times - each time more bloated than before. But the real problem with REST is that there is no schema. As a result, one cannot find errors without running the code, and that's awful for productivity. Now Google has come up with "protocol buffers" - essentially they are reinventing IIOP/CORBA - I guess they figured out that it is USEFUL to have the endpoints statically defined!!!
Cancel
Overall this is a good article but for the sake of ubiquity I think it's necessary to point out a few items of clarification that Gartner has provided with regard to the definition of microservices. They define a microservice as a private, isolated endpoint (hosted in a container such as Docker) with a single purpose. It's data is also meant to be isolated, meaning that it should not be part of a larger, normalized data model. Based on their definition, I would say that a true microservice is meant to be stateless. If the service is public or is not hosted in it's own container Gartner calls it a "miniservice".
Cancel
Another important issue is performance. XML-based and JSON-based message apps are ten times less efficient than apps with binary protocols. That's why Google developed Protocol Buffers. If you want to pay for ten times as many servers to run your app, then by all means, use REST!

Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close