This post shows a WCF service with a method exposed both as a SOAP-based and REST-based endpoint.
| WCF SOAP | WCF REST | |
|---|---|---|
| Abbreviation | SOAP stands for Simple Object Access Protocol | REST stands for Representational State Transfer |
| Definition | The Simple Object Access Protocol (SOAP) is an attempt to define a standard for creating web service APIs. It is a pattern, a web service architecture, which specifies the basic rules to be considered while designing web service platforms. It typically uses HTTP as a layer 7 protocol, although this is not mandatory. The SOAP message itself consists of an envelope, inside of which are the SOAP headers and body, the actual information we want to send. It is based on the standard XML format, designed especially to transport and store structured data. SOAP may also refer to the format of the XML that the envelope uses. SOAP is a mature standard and is heavily used in many systems, but it does not use many of the functionality build in HTTP. While some consider it slow, it provides a heavy set of functionality which is a necessity in many cases. It might now be the best solution for browser-based clients, due to its custom format. |
The Representational State Transfer (REST) is another architectural pattern (resource-oriented), analternative to SOAP. Unlike SOAP, RESTful applications use the HTTP build-in headers (with a variety of media-types) to carry meta information and use the GET, POST, PUT and DELETE verbs to perform CRUD operations. REST is resource-oriented and uses clean URLs (or RESTful URLs). For example : http://www.PlanetofCoders.com/index.aspx?page=RestPagebecomes http://www.PlanetofCoders.com/RestPageThis kind of URLs syntax greatly improves both visibility and usability. It doesn’t use any query strings, and it also provides certain SEO benefits (the crawlers just love plain text). The body of the REST message can be XML, JSON or any other format, although JSON is usually the preferred choice. On the other hand, you can’t use JSON with SOAP. Or at least not entirely, because SOAP uses XML by definition for it’s envelope. It should also mentioned that REST is, by design, protocol-agnostic, although it is usually used with HTTP. |
| Developer View | Object Oriented | Resource Oriented |
| Technology | SOAP services are operation based, which in general are used in business logic needs. SOAP is a protocol specification for exchanging data between two endpoints. A SOAP client application calls a method that is published as a web service operation on a remote server. The client receives a SOAP response in return. Web services expose an organization’s capabilities, such as automated ordering and pricing services that customers can use. | REST services are resource-based; REST is an architectural style for building client-server applications. REST relies on the semantics of HTTP protocol like Get, Post, Put and Delete so on. A client sends an HTTP request, much the way an Internet browser does, and receives a resource in return, such as data, video, or images. |
| Protocols | WCF SOAP services support a wide range of transport protocols, including HTTP, TCP and PIPE etc. | WCF REST services only support HTTP. |
| Transactions | WS-AtomicTransaction | No |
| Security | SSL, WS-Security based. SOAP-based service, because of the extra protocols specified in the various WS-Security specifications, does support end-to-end message security. This means that if you pass SOAP messages from endpoint to endpoint to endpoint, over the same or different protocols, the message is secure. SOAP with WS-* enables end-to-end message-level security is the source of the misconception that SOAP-based services are more secure than REST services. | SSL based. Even in REST we can provide some form of HTTP-based authentication plus Secure Sockets Layer (SSL). But in my view both of them are secure. |
| Reliability | WS-ReliableMessaging | Application specific |
| Interoperability | SOAP services are designed to be interoperable way to communicate between different platforms and different languages, such as Java or ruby or python. SOAP services messages add a significant overhead to support this. This overhead may be a matter of concern, in terms of performance and scalability, if your application has many transactions, complex data structures, and handles large volumes of data. Moreover I think SOAP services are more complex than REST services. | REST uses HTTP Stack which is better known; hence I think REST is more interoperable. |
| Performance | Good | Better |
| Caching | No | GET operations can be cached |
| Metadata | Using WSDL makes generating a proxy for a SOAP-based service easier than writing the code to call a REST service. | In contrary, REST services provide help pages support where you can see XML and Json implementation for request and response object from where you can construct classes or objects. |
| Message Communication Protocol | XML | XML, JSON, other valid MIME type. |
| Message Encoding | Yes | No |
| Human Intelligible Payload | No | Yes |
| Developer Tooling | Yes | Minimal or None |
| Orientation | Wraps business logic | Accesses resources/data |
| Who is using | Google seems to be consistent in implementing their web services to use SOAP, with the exeception of Blogger, which uses XML-RPC. You will find SOAP web services in lots of enterprise software as well. | All of Yahoo’s web services use REST, including Flickr, del.icio.us API use ir, pubsub, bloglines, technorati and both eBay & Amazon have web services for both REST & SOAP. |
| Transport Protocol | HTTP, SMTP, JMS | HTTP |
| Where to use | In my opinion, SOAP services with SOA architecture are well suited in enterprise applications. SOA architecture includes several key factors like service versioning, scalability, deployment and maintaining of services. | REST services are best suited in Internet-facing applications, which can take advantage of HTTP caching and other features. |