BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Since the dawn of the service-oriented architecture (SOA) evolution, SOA has been compared and contrasted with...
the Web model of the "RESTful" interface. While a lot has been said about the differences, most of the discussions have been arcane, and enterprises still report they're confused about what makes one model better than the other.
Most application architects realize it's possible to combine representational state transfer (REST) and SOA under at least some situations and gain advantage by doing so, if the applications are suitable and the development practices reflect the goals and benefits of both approaches. The biggest question is whether the goal is to develop a RESTful interface throughout while meeting most SOA goals, or to create a hybrid of REST and SOA.
Breaking down SOA, REST
SOA is an architecture designed to facilitate the development of flexible, agile applications by reusing common components within a general model of workflow management. The components are loosely coupled, meaning components are located via a publish/subscribe registry process, and they are linked using a general object access mechanism (typically the simple object access prototol or SOAP) that uses a definition language (Web services description language or WSDL) to describe the features and interfaces that link user and provider. The model supports standard mechanisms for identity, security and recovery processes and so is functionally rich in supporting complex business-critical applications.
The classic approach to creating a REST/SOA symbiosis is to add a Web server front-end to a SOA application.
The RESTful model was designed for simple user access via a browser. While this hypertext markup language (HTML) look-and-click navigation approach has been expanded to allow for more structured (extensible markup language or XML) information exchanges between program elements and not just with users, the basic interface is the same; the components are represented as uniform resource locators (URLs) and decoded using Internet-compatible domain name system (DNS) mechanisms.
Component coupling, arguably, is beyond loose -- it's nonexistent except as the users themselves might select among links visually. RESTful services are easy to develop and deploy, lightweight, inexpensive to host and maintain, and ideal for typical online applications.
The classic approach to creating a REST/SOA symbiosis is to add a Web server front-end to a SOA application, which makes SOA applications directly Internet-ready and lets them be accessed by browser/thin-client tools. This is fine where it's determined that the value of SOA's application-composition flexibility is high, but the growing importance of thin clients, mobility and Web access has prompted some architects to look at applying more RESTful concepts within the applications themselves.
Keys to RESTful SOA
For application architects, the key in creating a kind of RESTful SOA is the definition of the objects that will represent processing elements/resources. In REST, each object is represented by a URL and the user of the object is responsible for including state information in each message so that the object's processing is always stateless. Objects that are too complex, in that they represent multi-stage processes, will be difficult to code in RESTful form and their use will require transformational design patterns or other adapting mechanisms.
The next-biggest issue in RESTful SOA is managing the composability and binding process. One of the biggest objections of enterprises to formal (SOAP-based) SOA is that this level of discovery and binding flexibility isn't useful enough to justify the complexity. They report most applications have relatively static components, and that where components are introduced dynamically, they're typically representing functionality exposed by another application or even another user via an application program interface (API) -- which ironically is often RESTful!
It is possible to provide directory-based component discovery processes for RESTful interfaces if this level of dynamism is needed, but such needs may mean that a hybrid approach that uses REST at the front-end portion of the application and SOA/SOAP at the back end is justified.
Some application architects may have concerns about the security of RESTful interfaces. In a strict sense, the same encryption options are available for both, but in SOA/SOAP, the developer has more explicit control over security. However, RESTful applications can mandate secure connections and the developer can ensure this is done. The issues with auditing whether security has been imposed can be resolved by testing insecure HTTP calls to the interfaces to ensure no connection is permitted in that mode.
Orchestration and workflow threading are also sometimes cited as concerns when considering implementing SOA via RESTful interfaces. Of course, many message-bus protocols will support the use of RESTful interfaces (the specific support will depend on both the message bus and the selected programming language). What may be challenging is ensuring that backout procedures can be implemented if a transaction fails because of a component failure.
No explicit intermediary processes in REST and no specific mechanisms exist to ensure that a given RESTful process, having been successfully completed, can be reversed, much less what information is required to do that reversing. It is relatively easy to build a process map into a RESTful message and pass it from stage to stage so that a failure can be backtracked, but it may be necessary to develop this capability rather than to simply exploit a standard tool or capability.
The great majority of "services" implemented today are based on REST and not on SOA/SOAP, but enterprises have come to trust the formal SOA architecture for mission-critical applications. In applications where security/identity management, composability and compliance are absolutely critical, it may be difficult to reframe in RESTful terms. But for the average enterprise, the real question is whether the current application components demand SOAP or can be accessed in RESTful form.
Where REST is available, it likely offers a faster path to deployment, easier integration with customers, suppliers, and mobile workers, and more flexible GUI tuning for worker support. REST, as even its proponents will agree, is not a perfect solution, but for many SOA applications, it's the best solution.