SOAP/WS-* and REST: Complementary Communication Styles David Chappell Chappell & Associates www.davidchappell.com

SOAP, WS-*, and WCF REST and WCF Comparing SOAP/WS-* and REST: Making the Right Choice Agenda

Web Services Today Two approaches to Web services are in use today: SOAP and the WS-* specifications Representational State Transfer (REST) There is some competition between proponents of each approach Beginning with the .NET Framework 3.5, Windows Communication Foundation (WCF) provides built-in support for both Microsoft is agnostic in this debate

WCF Service WCF Client WCF Communication Basics Channels WCF communication relies on channels Channels can be grouped into channel stacks The lowest channel in a stack is always the transport channel

A WCF interface is associated with one or more bindings Each binding creates a channel stack with specific functions WCF Service [ServiceContract] interface IExampleB { . . .} [ServiceContract] interface IExampleA { . . .} WCF Communication Basics Bindings

SOAP, WS-*, and WCF

WCF Client WCF Service Access via SOAP Illustrating the approach

Access via SOAP A WCF interface [ServiceContract] interface IAccount { [OperationContract] int GetBalance(int account);   [OperationContract] int UpdateBalance(int account, int amount); }

Access via SOAP A WCF binding <endpoint address="http://www.qwickbank.com/AccountAccess/ Accounts.svc" contract=“AccountApp.IAccount" binding="basicHttpBinding“ />

BasicHttpBinding WCF Application WCF Binding for SOAP Using HTTP

Describing WS-* Messaging and security Messaging WS-Addressing: Allows using SOAP over any transport protocol, not just HTTP Message Transmission Optimization Mechanism (MTOM): Allows sending binary data efficiently Security WS-Security: Defines a way to convey various security tokens and more WS-Trust: Defines how to request and receive security tokens WS-SecureConversation: allows establishing a security context, e.g., for more efficient encryption

Describing WS-* Reliability, transactions, policy, and metadata Reliability WS-ReliableMessaging: Allows reliable end-to-end communication through multiple SOAP intermediaries Transactions WS-AtomicTransaction, WS-Coordination: Define how to convey transaction contexts and do two-phase commit for distributed ACID transactions Policy WS-Policy: Allows defining policies in various areas, e.g., security policies with WS-SecurityPolicy Acquiring interface definitions: WS-MetadataExchange: Allows accessing a service’s WSDL definition and more

WSHttpBinding WCF Application WCF Binding for SOAP/WS-* Using HTTP

NetTcpBinding WCF Application WCF Binding for SOAP/WS-* Using TCP

Access via SOAP/WS-* Specifying WCF bindings Using WS-Security, WS-ReliableMessaging, and/or WS-AtomicTransaction with WSHttpBinding or WSTcpBinding requires configuring the binding correctly These configurations can get complicated Especially for security WCF’s Configuration Editor Tool (SvcConfigEditor.exe) helps some

WS-* in the Real World WCF isn’t yet the dominant technology for Web services on Windows Which makes the WS-* technologies less widely available Cross-vendor interoperability for SOAP and the WS-* technologies isn’t perfect Developers expect types to move unchanged from .NET to XML to Java, which is hard

REST and WCF

WCF Client WCF Service Access via REST Illustrating the approach

Defining REST An architectural style Two core principles: Everything is accessed through a uniform interface All data is identified with a URI Some subsidiary principles: Be stateless Be cacheable whenever possible More . . . A first-rate description of REST: RESTful Web Services, by Leonard Richardson and Sam Ruby

Access via REST A WCF interface [ServiceContract] interface IAccount { [OperationContract] [WebGet] int GetBalance(string account);   [OperationContract] [WebInvoke] int UpdateBalance(string account, int amount); }

The Semantics of HTTP Verbs A closer look REST typically depends on HTTP’s verbs Primarily PUT, GET, POST, and DELETE The semantics of GET are well-defined The semantics of the others are more ambiguous An example from the HTTP 1.1 spec:

WCF Support for REST Specifying verbs and data formats The Method parameter for WebInvoke allows specifying HTTP verbs other than POST, e.g.,: [WebInvoke(Method=“PUT”)] The ResponseFormat parameter for WebGet and WebInvoke allows specifying how information is sent: XML (the default) JavaScript Object Notation (JSON) Binary

WCF Support for REST Working with URIs RESTful communication typically requires working with lots of URIs Every resource has its own URI URIs for a particular application commonly have a common format Such as Accounts/<number> URI templates can make it easier to work with large numbers of similar URIs, providing: A way to express URI patterns Support for working with URIs that match those patterns

Access via REST Specifying a WCF binding The configuration is fairly simple: Specify binding=“webHttpBinding” Set the webHttp behavior for this endpoint Alternatively, an application can use WebServiceHost instead of ServiceHost This defaults to webHttpBinding with the webHttp behavior No configuration is needed

WebHttpBinding WCF Application WCF Binding for REST Using HTTP

WCF and RSS/ATOM An aside WCF 3.5 adds built-in support for using RSS and ATOM, including: New types SyndicationFeed and SyndicationItem, which can be used to construct a feed containing one or more items Separate formatters for RSS and ATOM, allowing this data structure to be output using either option RSS and ATOM are formats, not protocols, so no new binding is required Since they’re typically sent over HTTP, WebHttpBinding is usually the right choice

Truth in Naming Calling SOAP-based services “Web services” makes no sense SOAP is the culmination of a long line of RPC protocols, including DCE RPC, CORBA, DCOM, Java RMI and .NET Remoting It has little to do with Web technologies REST-based services truly deserve the name “Web services” They’re entirely based on Web technologies: HTTP and URLs

Comparing SOAP/WS-* and REST: Making the Right Choice

Areas for Comparison Exposing operations vs. exposing data SOAP/WS-* and REST emphasize different things Capabilities SOAP/WS-* and REST provide different functions

Operations vs. Data What is exposed? REST Focused on accessing named data Every application exposes its data through the same interface Relying on HTTP and URLs doesn’t require any special library SOAP Focused on accessing named operations, each of which implements some logic Different applications provide different functionality, and so each one has a different interface Relying on SOAP requires a SOAP stack, WSDL, and maybe implementations of the WS-* specs

RESTful Data Access Amazon’s Simple Storage Service (S3) S3 allows storing Objects in Buckets Much like storing files in directories Both Objects and Buckets are identified with URIs Operations: GET Object: returns the contents of this object GET Bucket: returns a list of objects in this bucket PUT Object: creates a new object PUT Bucket: creates a new bucket DELETE Object: deletes an object DELETE Bucket: deletes a bucket S3 also provides a SOAP-based interface

RESTful Data Access The benefits of caching For many (most?) services, the majority of client requests are reads In a RESTful service, all reads rely on HTTP GET The results of a GET are commonly cached This can allow better performance and more scalability for RESTful services exposed over the Internet

SOAP-based Operation Access The banking interface shown earlier A service for banking functions might include operations such as: GetBalance(Account) UpdateBalance(Account, Amount) These work well with either REST or SOAP Suppose the interface must also include: Transfer(FromAccount, ToAccount, Amount) This doesn’t map well to REST’s data-oriented model It’s exposing logic, not data access

SOAP/WS-* and REST A capability summary SOAP/WS - * REST

Broad Standardization vs. YAGNI Two views of the world Broad standardization: Provides a wide range of functionality Allows interoperability, since everyone provides the capability in the same way Increases the odds of correct implementation, since each vendor implements (and tests) the capability once rather than each application developer doing it YAGNI: You Ain’t Gonna Need It, so keep things simple

Security REST RESTful services commonly use HTTPS Standards for carrying security tokens: HTTP for username/password SSL for X.509 certificates This is sufficient for many scenarios

Security SOAP/WS-* SOAP-based services can use HTTPS Standards for carrying security tokens: WS-Security for: Username/password X.509 certificate SAML token Kerberos ticket WS-Security also defines how to use: XML Signature for integrity XML Encryption for privacy WS-Trust defines: How to acquire security tokens

Transactions Using WS-AtomicTransaction ACID transactions that span multiple applications and/or databases are an important part of enterprise computing They’re not all that common, but they’re still important ACID transactions don’t usually make sense across the Internet They’re mostly used within an enterprise WS-AtomicTransaction addresses this problem It relies on WS-Coordination

Transactions A simplified WS-AtomicTransaction example Java EE .NET Framework .NET Application EJB Application Internet

Reliability REST Assumes the application deals with communication failures via application retries SOAP with WS-ReliableMessaging Builds acknowledgement/retry logic into the communications stack Can provide end-to-end reliability through one or more SOAP intermediaries

Making a Choice SOAP/WS-* or REST? Neither is right for every situation Each has its place Some questions to ask: Does the service expose data or logic? REST can be a good choice for exposing data SOAP/WS-* can be better for exposing logic Does the service need the capabilities of WS-*, or is a simpler RESTful approach sufficient? What’s best for the developers who will build and use the service? REST has a lower barrier to entry in some ways SOAP’s operation-oriented approach will feel more natural to many

Conclusion Both SOAP/WS-* and REST have good futures WCF supports both The best decisions come from reason, not emotion

For Further Reading Dealing with Diversity: Understanding WCF Communication Options in the .NET Framework 3.5 http://www.davidchappell.com/articles/white_papers/WCF_Diversity_v1.0.docx

About the Speaker David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, he helps IT professionals understand, use, and make better decisions about enterprise software. David has been the keynote speaker for dozens of conferences and events in the U.S., Europe, Asia, Latin America, and Australia. His popular seminars have been attended by tens of thousands of developers, architects, and decision makers in forty countries. David’s books have been translated into ten languages and used regularly in courses at MIT, ETH Zurich, and many other universities. He is Series Editor for Addison-Wesley’s award-winning Independent Technology Guides, and he has been a regular columnist for several publications. In his consulting practice, David has helped clients such as Hewlett-Packard, IBM, Microsoft, Stanford University, and Target Corporation adopt new technologies, market new products, train their sales staffs, and create business plans. David’s comments have appeared in The New York Times, CNN.com, and various other publications. Earlier in his career, he wrote software for supercomputers, chaired a U.S. national standardization working group, and played keyboards with the Peabody-award-winning Children’s Radio Theater. David holds a B.S. in Economics and an M.S. in Computer Science, both from the University of Wisconsin-Madison.