Picking a winning Web service approach::http://webservices.sys-con.com/read/79282.htm

By: Dion Hinchcliffe

Apr. 26, 2005 11:00 AM

At their most basic level, Web services work well and solve important problems because they are based on standards. However choosing among the available Web service approaches can still be surprisingly difficult. Whether it is correct or incorrect, the choice will have far reaching consequences for any project. A foray in the wrong direction often means having to abandon the initial investment, in terms of development, training, and infrastructure, to retool everything to go another way. Make a good decision though, and Web services become an enabling springboard to enterprise integration, information self-service, and all the attendant benefits of service-oriented architecture. In a highly competitive business environment, the risk of lost time and investment means that making the best decision up front is vital to success.

Unlike a few years ago, there are now many good ways to build standards-based Web services. Some are easier and some are certainly better than others, but for most projects, it generally boils down to deciding between two competing technical approaches: SOAP or REST. Since they both take the Web service creator down uniquely different paths, it’s worth spending time determining exactly where each approach leads. Even with care, making the decision correctly is difficult and will certainly be definitive for a Web services development effort. The difficulty is compounded by the ongoing debate over whether SOAP or REST is best for a particular application. Certainly there will be groups within an organization championing one direction or the other, but fortunately for those making decisions today, there is now hard-won field experience and lessons learned about both approaches to draw from. It’s time to take a close look at where SOAP and REST are, what they are really capable of, and where they are going. Though SOAP and REST are essentially the same in what they do, they couldn’t be more different in terms of how they work. Explained simply, SOAP and REST allow programs to exchange XML messages over a network, usually some flavor of the HTTP protocol used to serve up Web pages. HTTP is the ubiquitous workhorse protocol that forms the infrastructure of the Web and is used by Web clients billions of times a day to send and retrieve pages from Web servers around the world. By leveraging the proven and well-supported HTTP protocol for the physical transmission of pure data instead of visual Web pages, SOAP and REST provide clients access to reusable information services over a network while using technology standards that IT departments are already intimately familiar with. It’s no accident that because they both use popular and widely supported standards to provide services, SOAP and REST are held up as poster children of the Web services revolution. Web services are about interoperability, and SOAP and REST deliver the goods. First described by Roy Fielding in his PhD dissertation, Representational State Transfer (or REST) is based on the concept of transferring state between two systems on a network. This method is identical to the way in which a Web browser gets Web pages from or posts them to a Web server. With REST, the pieces of data that are transferred by the Web service must be identified individually using a standard addressing scheme. REST developers are encouraged to think of these addresses in terms of something called a Universal Resource Identifier, or URI, of which the ubiquitous Web page URL is subset. A URI uniquely identifies any kind of network resource for which a unique address can be created. In practice, URIs are assigned to individual data records, such as customer records or orders, transferred between the Web service and its client. REST’s URL-style lookup model is eminently familiar to all Web users and is just one way that REST leverages the successful aspects of existing Internet protocols. To cap off the REST model, the URI and an HTTP verb (GET, POST, PUT, DELETE) are used together to issue a request to a REST Web service to access and manipulate the server-side state, or data record, identified by the URI (see Figure 1fig1). The actual XML message is contained in the HTTP request and security is provided by HTTPS, which is the secure version of HTTP. This, in a nutshell, is virtually everything that a Web service user or creator needs to know about REST. In the other Web service camp is SOAP, a more formal, deliberate, and standardized solution to providing Web services. Fortunately, the structure and internal moving parts of SOAP messages are generally well organized and straightforward. Like REST, SOAP is an open messaging framework based on XML but is backed by formal standards from a recognized standards body, the World Wide Web Consortium (W3C). SOAP also has compelling built in extension mechanisms that make it an excellent choice as the basis of a Web service stack on which to build more advanced capabilities. Revised several times since it was originally issued in 2000, the current version, SOAP 1.2, now lets the Web services creator decide on the exact network protocol to use. This can still be HTTP but could just as easily be SMTP, the Internet mail protocol. SOAP messages themselves are embodied by an XML document known formally as the SOAP envelope. The SOAP envelope consists of two parts, a header and a body. The header contains optional control information about the message. The SOAP header is both novel and highly useful in that it allows SOAP messages to be annotated in a standardized way (see Figure 2fig2). This allows a SOAP message to carry along descriptive metadata information about security, transactions, or other useful context that does not change the message itself but describes higher-level processes of which it is a part. The SOAP body portion of the envelope contains the actual XML message being transmitted. Appreciating the standardized yet extensible design of SOAP is part of understanding the unique appeal of the SOAP model. Because many other interesting Web protocols can and do plug into SOAP via its header mechanism while treating the message carried as inviolate, SOAP becomes a powerful intermediary between sophisticated systems that can process various parts of the message. These services can plug into SOAP messages by providing extensions for security, orchestration, transactions, and other features. It is specifically this capacity for extension that makes SOAP so interesting to organizations wishing for standardized ways of using sophisticated, enterprise-class capabilities with their Web services. If nothing else, SOAP will remain popular for this capability, though other features, such as having schema support, also make SOAP a good choice for its ability to describe the data it carries.

Beyond the Basics: sSOAP/REST Differentiators

Beyond their similar means for XML message exchange over HTTP, SOAP and REST have little in common. Unlike REST, SOAP is a recognized W3C standard that describes a consistent way to exchange XML messages. In SOAP-based Web services, XML formatted SOAP envelopes are exchanged over a selected protocol with XML messages that are described with a schema. The wire protocol is flexible with SOAP, which it isn’t with REST, and SOAP is able to use a growing variety of other network protocols in a standardized fashion. SOAP’s message format is more technically intricate and rule-constrained than REST, but this also facilitates the underpinning of a layer of associated Web services that are based on a series of other standards. This Web services stack ostensibly offers a “solved” Web services architecture to organizations that want it. It’s worth noting though that many of these value-add Web services are still in development, well-known projects such as Microsoft’s Indigo project, which isn’t due for many months, are intent on delivering advanced services on top of SOAP for widespread use.However all complexity comes at a cost. This means SOAP can be difficult to deal with when things go wrong and the problems have to be figured out. To allay this somewhat, SOAP also has quite good tool support, with many commercial software vendors offering SOAP-aware products across the spectrum of design, development, monitoring, and management. In contrast, software support for REST seems relatively stark, especially on the management and administration side. Many REST advocates would counter that existing tools that manage HTTP and SSL already do the job. SOAP’s formalized and federation-friendly nature stands in almost direct opposition to REST. In reality, REST isn’t even a Web services standard. It is an architectural style that leverages the popular Internet standards XML and HTTP. REST is about, and really only about, the XML message being exchanged over a network. To understand REST, one merely needs to visualize a block of XML and think about HTTP’s simple verbs (GET, POST, PUT, and DELETE). REST uses these verbs to access and manipulate the information like a resource on the network, like a browser uses a Web page. REST can appear simplistic, even crude, when compared to SOAP, but in reality, most users find it lightweight, flexible, and easy to use and debug. Due largely to its lack of complexity, relative ease of development, and little need for tools, REST has been extremely successful in grabbing development mindshare. REST also has a proven track record for performance and scalability. For example, Amazon reports that it now has over 50,000 users of its Web services, and most of them are using the REST interface. Fewer than 20% of Amazon’s Web service clients use Amazon’s SOAP interfaces. Also, while Amazon reports SOAP usage is trending upward, REST usage continues to climb in other places, including GM’s massive internal Web services restructuring. From a tool perspective, REST, unlike SOAP, has comparatively little commercial software support, although this is often considered a feature because REST doesn’t actually need much in the way of tools that aren’t already at hand, such as a Web browser for debugging.

Summary of SOAP and REST

See Table 1table1 REST

  • Messages are represented in plain XML
  • HTTP is used for the transfer protocol
  • HTTP verbs are used for access/manipulation commands
  • URIs are used to uniquely identify resources in message
  • HTTP authentication provides security
  • There is no formal method for expressing the interface contract

SOAP

  • Messages are represented in a standardized XML SOAP “envelope”
  • Can be bound to various protocols including HTTP and SMTP
  • Access to and manipulation of data are application specific
  • Security is not described by SOAP and is to be provided by the developer
  • XML schemas are used to define the contract between client and service

In the past couple of years there has been intense debate within the Web services community about the virtues of both SOAP and REST, or their perceived lack thereof. Despite almost universal support by the .NET and Java platforms, there are many who believe that SOAP is having some adoption challenges in the industry, mainly due to perceived complexity. On the other hand, REST has been quietly growing in popularity, partially as an underdog and partially because it is not exclusionary, but mostly because of ease of implementation. At the same time, supporters of SOAP are continuing to make it more robust, more extensible, and easier to use. So which approach is best? It really depends on the requirements, but there are certainly compelling reasons for using either. REST thrives on its spare design and relatively informal techniques and it requires no additional development tools, yet SOAP is powerful and sophisticated (though sometimes to the point of obscurity). The development and management tools available today for SOAP matured considerably and their features are compelling. For many applications, especially full-blown service-oriented architectures, the various W3C Web service additions (known as WS-* extensions) are almost a necessity. When it comes down to meaningful differentiators, an important difference between REST and SOAP is the ease with which management and troubleshooting can be done with them. SOAP is very routing- and processing-centric, with various flags that indicate whether a message must be fully understood by an intermediary and dealt with. For its part, REST can be debugged with a garden variety Web browser. As for true interoperability, REST message aren’t standardized, which can make them harder to manage or monitor using off-the-shelf tools since their content is not documented in a way that commercial tools can understand. SOAP however has an extensive array of professional applications that can be used to manage, monitor, route, and process it. Due to lower messaging overhead, REST is generally considered faster than SOAP. Though use of text-based XML in Web services already causes bloat on the network with both approaches, SOAP, which is often used in conjunction with the WS-* protocol extensions, further exacerbates the problem by adding special handling and processing requirements. Amazon, one of the leading implementers of the REST, claims that REST is up to six times faster. Another important way of looking at Web services approaches is to consider them from an interoperability standpoint. Proprietary products like Web service development tools, platform-driven Web services like .NET’s .asmx approach, and legacy system integration efforts that expose older systems through Web services typically use SOAP instead of REST. This tends to pollute the Web service with idioms and patterns from the underlying system, language, or tool. This makes it much more difficult for those without the same environment to consume them. But those with the same Web service toolkits on both ends of the network will likely have much less trouble. They will also be able to take advantage of more advanced layers of services like those built on top of SOAP. Fundamentally, Web services are about the XML message itself, the angle brackets and text that travel on the network wire. The contract that a Web service offers, namely the promise to do something in exchange for communicating using an agreed upon message format, is the key to the promise of true interoperability between communicating systems of Web services. The use of plain XML as the native data format of Web services means that they are usable from any client, any system, anywhere in the world. Anything that convolutes this process reduces the ability to interoperate. Major organizations with international presence, such as Amazon and Flickr, have proven that Web services can be consumed successfully by a large and highly diverse audience. REST tends to support and embrace this diversity and foster fundamental interoperability, albeit in a different way the SOAP does, which uses large, formal standards to try to achieve the same result. In the end there is no clear winner for every application. Selecting a Web service approach is highly situation based. REST is a very attractive choice for more basic applications that involve high levels of interoperability between multiple platforms. SOAP is very appropriate for larger, formal applications that require advanced capabilities between relatively homogenous systems. SOAP’s ability to leverage standard Web protocols such as WS-Security, WS-Policy, and WS-Transactions make rich functionality easy to deliver quickly, but at the expense of interoperability. Unfortunately, users without ready access to working implementations of W3C Web service standards in their development toolkits are unlikely to be able to develop support for them on demand. This means SOAP’s ability to layer advanced capabilities together, perhaps too easily, tends to shut out those that don’t have ready access to them. Some observers take the long view, that SOAP, and its associated WS-* standards will ultimately be ubiquitous and no one will lack the ability to interoperate. Adherents to REST will be achieving value along the way, asking all along why it took so long for everyone to get there. In the end, however, the details of the Web service wire protocol are growing increasingly less interesting as the real challenges become clearer. The power and appeal of Web services are often lost when the focus is exclusively on the lowest level of the Web services story. There is also a growing concern in the industry that the proliferating array of Web service standards and efforts is fragmenting the market and decreasing their ability to interoperate. Beyond this, though, Web services deliver far more value when the view goes beyond the simple messaging that SOAP and REST provide. Though this decision on the Web service approach is important, the real goal is to get beyond this point, to the level of service-oriented architecture, where more meaningful concerns become visible. Issues such as information policy, business processes, governance, and consistent semantics are what make the Web services interesting, and more important, what makes them a genuine contributor of value to the organization.