Often the acronyms REST (representational state transfer) and SOAP (simple object access model) are used when describing web services, almost as though the two can be directly compared.

SOAP is an XML based protocol. REST is an architectural style. When used in the context of services, a service that implements REST architecture is said to be RESTful.

Let’s examine both REST and SOAP in the context of web services. Both REST and SOAP have value, the key is knowing when to implement each one.

RESTful services are focused on accessing named resources through a single constant interface.

SOAP has it’s own protocol and exposes operations. It focuses on accessing named operations that each implement some business logic through different interfaces. SOAP is commonly referred to as web services, however a RESTful service is a true web service based on URIs and http.

By way of illustration:

GetUser(user);

This is a RESTful operation as a resource is being accessed (data).

SwitchCategory(user, oldCategory, newCategory)

This is a SOAP operation as an operation is being performed.

Either of these could be accomplished in either a SOAP or RESTful service but the purpose is to illustrate the conceptual difference.

Benefits of RESTful services:

• Uses standard HTTP and as such is much simplier than SOAP
• Permits different data formats: XML and json (default)
• Reads can be cached (SOAP cannot)
• Better browser support due to json format

Benefits of SOAP services:

• Supports ws-security, which adds enterprise security features
• ACID (Atomicity, Consistency, Isolation, Durability) compliant via ws-AtomicTransaction (add link to wiki)
• Successful/retry logic built in through ws-ReliableMessaging
• Encrypted at the message level, rather than the transport level. So can be harder to decrypt than SSL.