Home > REST Service vs. Non-REST Service Contracts > HTTP Messaging vs. SOAP Messaging

HTTP Messaging vs. SOAP Messaging

Using WSDL and SOAP-based Web service messaging as a point of comparison, let's get a deeper insight into what distinguishes REST services messaging from HTTP.

In the following example, a simple SOAP message is sent to a WSDL-based service contract to request an invoice based on its ID:


Next we have the response message returned by the Web service, providing a SOAP message containing the invoice content:

			<Invoice> ...invoice content... </Invoice>

The equivalent exchange with a REST service relying on the use of HTTP methods would be as follows:

GET http://invoice/invoice/I123 HTTP/1.1
Accept: application/vnd.com.example.invoice+xml

The response HTTP message that is returned to the service consumer contains a success code, the media type header statement, and the same XML fragment as the response message from the Web service, as highlighted here:

200 OK
Content-Type: application/vnd.com.example.invoice+xml
<Invoice> ...invoice content... </Invoice>

The SOAP messages exchanged with the WSDL-based Web service require the service consumer to know:

  • the service name: http://invoice/
  • the service-specific operation (service capability): getInvoice
  • the service-specific invoice document identifier: inv123
  • how to invoke the service capability
  • how to interpret service-specific response messages
  • how to interpret service-specific exceptions

The messages exchanged via HTTP require the service consumer to know:

  • the generic method for retrieving the invoice document: GET
  • the resource identifier for the invoice document: http://invoice/invoice/I123
  • how to invoke the service capability (method + resource identifier)
  • how to encode the received invoice content (for example, using the
  • application/vnd.com.example.invoice+xml media type)
  • how to interpret HTTP response codes (such as 200 OK)
  • how to interpret generic HTTP exceptions

Throughout a service inventory with REST services, this particular invoice will not be referred to as I123, but instead as http://invoice/invoice/inv123. Whenever a service consumer is required to retrieve the identified invoice, it needs to be prepared to invoke the HTTP GET method. In doing this (on what it knows is an invoice resource) the service consumer is already expected to be able to process invoice data in the corresponding response.

It is further expected that throughout the service inventory, all services and service consumers that interact with invoice resources understand the uniform contract media type for invoice data: application/vnd.com.example.invoice+xml