Many web service providers offer both a SOAP API and a REST API, so the consideration of which to use comes up moreoften than you'd think. Each technology has attributes that make it more or less suitable for various purposes. The typical scenario is that companies first write SOAP methods, then port their SOAP API to a REST API. In such cases, where customers are presented with both APIs, this article might be helpful in deciding which way to go.
What's the difference?
If you were to ask me what's the difference between SOAP and REST in an elevator, and I only had 15 seconds to explain, I might offer this very basic, brief statement:
- With SOAP, you make method calls to invoke application operations remotely.
- With REST, you make HTTP requests to create, delete, update, and retrieve remote data.
However, if the elevator were then stuck between floors, after relating all my aches and woes, I'd finish my explanation as follows.
Let's look at commonalities and differences.
What do they have in common?
Both SOAP and REST are service oriented architectures (SOAs). SOA is a generic term for architectures that allow applications to interact remotely through mutually understood standard interfaces. There are other SOA protocols such as RPC, CORBA, DCOM, and WCF, but we're only considering SOAP and REST here.
For an end user, there's no discernible difference in the operation of REST and SOAP web services. Their purpose appears to be the same--to access information in a language- and browser-agnostic manner, using a disconnected, stateless transfer model. If implemented properly, each is reliable, secure, and reasonably efficient for its intended application.
For a developer implementing a web service application, however, there are many differences to consider.
SOAP: Simple method calls over a wire
Simple Object Access Protocol (SOAP) is a software architecture that allows applications to consume web services by means of method calls. Your application calls methods that execute on a remote server. The data can be transported via various transport protocols such as HTTP/S, DCOM, or SMTP (HTTP is most commonly used).
You call SOAP methods as you would any method call, except that with SOAP, method execution is performed remotely. This makes SOAP language agnostic. You can call a SOAP method from an application written in any language, and execution occurs on a remote server. The method call only needs to know the signature of the web service interface (the parameters and return type) and the service endpoint (the address of the web service on the server).
A SOAP application uses Web Services Description Language (WSDL) to define how the service is called. This info is contained in a .wsdl file in the project. The WSDL defines what operations are available on the server, the method signatures of these operations (parameter and return types), and the address of the service endpoint for the operations.
SOAP transfers request and response data as XML text in a structured message consisting of a SOAP envelope containing a header and a body. The header contains application-specific metadata such as authentication and encoding. The body contains the actual SOAP data sent--either input data sent to the service endpoint for processing, or result data that the server returns to the client.
REST: All the web's an address
Representational State Transfer (REST) is a software architecture based on client-server interaction. A client application sends standard HTTP method requests to a remote server, which processes the request and returns a response. Applications often use HTTPS for secure data transfer. REST is a disconnected, stateless transaction model. A client request contains all the information necessary to service that request; session state is stored on the client.
The standard HTTP calls correspond to operations on resource data, similar to CRUD (create, read, update, delete) operations, as follows:
- GET corresponds to a read operation
- PUT corresponds to an update operation
- POST corresponds to a create operation
- DELETE corresponds to a delete operation
In the REST model, everything on the web is considered a resource. All data, such as text, images, audio, etc., are resources, as are data processing and data access services. For example, a web service could look up an address for a specified contact, or edit that contact, or reformat the phone number that the user provides before writing it to the contact entry.
Each resource has an address represented by a Uniform Resource Identifier (URI), the address of the resource in the resource model. The exact structure of the URI depends on the web service's particular architecture. In general, it consists of a base URI, which defines the service endpoint address, followed by an extended address for resources and subresources. All REST APIs expose resources in a hierarchical structure called a resource model, in which each resource has a specific URI path.
A client application can send data either as parameter data in the URI, as header data, or in the request body. Response data is returned by way of the request body. Request and response data can be sent in a number of different formats such as ATOM, JavaScript Object Notation (JSON), RSS, POX (Plain Old XML).
How they stack up in comparison
Transfer protocols
- REST is limited to HTTP.
- SOAP is not limited to any one transfer protocol. SOAP can transfer data using other protocols such as SMTP, TCP/IP, named pipes, or message queues. Also, SOAP doesn't use standard HTTP requests but rather makes direct method calls over HTTP. Therefore the call doesn't have to originate from an application running in a web browser.
- With REST, you must fully understand the resource model in order to use it. REST calls are simple, but the client needs to call the correct address with the correct HTTP verb. Resource models can be extensive and complex. This is not a disadvantage of the architecture, but it can be confusing if the resource model is not well understood. (Hence it's critical that the REST API documentation exposes the resource model.)
- In SOAP, calls from the client application must match the method signature of the SOAP interface being called.
- REST is ideally suited for web applications; you can access web services from web applications in any browser. Because it only uses standard HTTP commands, REST functionality is browser agnostic. Operations are extremely simple, yet can access sophisticated functionality on the remote server (for example, identity verification and authentication). It is ideal for secure transactions such as online banking. Because it is disconnected, session state can be preserved.
- SOAP is language agnostic; you can make the call from an application written in any language, and execution occurs on a remote server. However, you must make sure that the type of data sent matches that required by the SOAP interface. Because the data is transported in a standardized structure, it makes a web service widely accessible.
- REST supports several data formats such as JSON, Atom, and POX (XML), and can transfer data as binary streams to increase throughput efficiency. Clients can cache responses, so you can reduce client-server interactions and improve performance.
- SOAP transfers data as verbose XML, so the messages are larger than binary data formats, and performance is slower than competing protocols. It might not be the best protocol for applications that compute or transfer large data sets.
- With REST, all you need to call the service is a browser. The API is super simple--only the four HTTP methods and the URI--but you need foreknowledge of the service endpoint and the address of each resource. Also, then your client app needs to parse and interpret the response from each call.
- With SOAP, you can discover the service with the WSDL service description, which can give you a usable client proxy. The XML returned by SOAP calls is easy to interpret.
The elevator starts moving, so in conclusion...
To conclude, there's no right answer. Both technologies are extensively used and well-proven. While you could argue that REST has been around since the beginning of Internet time (as long as there has been an HTTP request), it's considered the newer technology. SOAP has enjoyed a lot of corporate support, but never caught up with REST. SOAP started out strong in the early millennium, but it's distinctly falling from grace. As one example, Ruby on Rails dropped SOAP from its core framework in 2007.
This is not to say you shouldn't choose SOAP. It's simply that there are compelling reasons why REST is so much more appealing.
