This document compares and contrasts REST and SOAP architectures. It notes that REST uses HTTP and identifies resources with URIs, represents resources through representations, and uses hypertext to manage application state. REST is client-server, stateless, caches resources, and has a uniform interface. SOAP uses defined operations like GetAccountBalance() rather than resources, always uses XML, and focuses more on message security than reusing web security standards. Both support service-oriented architectures.

1. Muhammad Adnan Khan (CANS)

2.  Resources are identified by uniform resource
identifiers (URIs)
 Resources are manipulated through their
representations
 Messages are self-descriptive and stateless
 Multiple representations are accepted or sent
 Hypertext is the engine of application state

3.  Client-server
 Stateless
 Cached
 Uniform interface
 Layered system
 (Code on demand)

4.  REST: Resources
 Start with the data/entities/resources first
 Define the URI
 Then expose uniform interfaces:
 Create/Read/Update/Delete
 SOAP: Operations
 Procedural (RPC over HTTP)
 GetAccountBalance(), SubmitOrder()

5.  Protocols
 REST – HTTP
 SOAP – usually HTTP but can also use TCP, MSMQ,
SMTP, File, etc.
 Transport Independent
 Representations (Data Format)
 SOAP – always XML
 REST – XML, JSON, XHTML, anything

6.  REST: Re-use existing web security
 SSL and HTTP Authentication (Basic, Digest, WSSE)
 SOAP: Protocol and message security
 SAML assertions, Kerberos tickets, X.509
certificates
 WS-Security: Defines how to convey various security
tokens and more. Support for identity through SOAP
intermediaries. Not just point-to-point.
 WS-Trust: Defines how to get security tokens
 WS-SecureConversation: Allows establishing a security
context

7.  Properties of REST Architecture
 Addressability
 Uniform Interface
 Statelessness
 Connectedness
 Both REST and SOAP support SOA