SOAP versus REST

Web Services fall into two architectural styles, SOAP and REST.

SOAP, originally defined as Simple Object Access Protocol but now simply SOAP, is a formal specification for the exchange of structured information via Web Services. It relies on XML for its message format, and uses HTTP (which is really an application layer protocol) as its transport protocol. Historically, HTTP was the mechanism used to get through firewalls (since almost all firewalls allow HTTP traffic to pass through) and remains in use today. Note also that HTTPS may also be used, since HTTP and HTTPS are identical at the application layer. The XML based message format consists of three parts: - , and a convention for representing procedure calls and responses.

An envelope, which defines what is in the message and how to process it.
A set of encoding rules for expressing instances of application-defined data types.
A convention for representing procedure calls and responses.

Representational State Transfer (REST) is not a formal specification, but a style of software architecture for distributed hypermedia systems. For example, the World Wide Web is considered a REST system. The term Representational State Transfer was defined by Roy Fielding in 2000 in his doctoral dissertation. REST was initially described in terms of the HTTP application layer protocol (Fielding was one of the principal authors of the HTTP specification) but is not limited to HTTP.

REST uses the HTTP methods as its verbs to implement a create/read/update/delete model for resources described by URIs. In particular, the HTTP GET method is a read-only access to a resource, PUT is a create request, POST is update, and DELETE is delete. There are additional constraints on a (so-called) REST-ful system, of which statelessness is the most pertinent to the programmer using BIS.

Proponents of REST consider REST to be superior to SOAP for several reasons:

REST makes consistent use of the HTTP methods, whereas SOAP uses only POST, although a GET on a service endpoint URL is interpreted as a request for the WSDL that describes the service. SOAP overloads the POST method which obscures the nature of a request. This interferes with caching and other performance related techniques used on the web.
Similarly, REST uses URIs to identify the unique resource being affected by a request. SOAP uses a single URI to identify a 'service endpoint' and describes the resource being affected by a request somewhere in the body of the request. As described above, this interferes with web performance techniques.
SOAP is tied to XML, and is considered by some to be wordy. However, modern HTTP servers have built-in compression capability which may counteract this disadvantage for SOAP.
REST can be associated with just about any web resource, whether XML-based or not. Remember that the World Wide Web is REST-ful.

Whether to use SOAP or REST in creating BIS service programs is probably decided by requirements external to the application system that cannot be considered in this tutorial. However, it is important to remember that Xcentrisity BIS provides the flexibility to participate in HTTP-based systems of either architecture.