Programming Amazon Web Services

Interfaces: REST and Query Versus SOAP

AWS infrastructure services are made available through three separate APIs: REST, Query, and SOAP. In this book we will focus only on the REST and Query APIs and will not demonstrate how to use the SOAP APIs. We have a number of reasons for doing this, reasons which will become clearer after a brief explanation of the differences between the interfaces.

REST interfaces

The REST interfaces offered by AWS use only the standard components of HTTP request messages to represent the API action that is being performed. These components include:

• HTTP method: describes the action the request will perform

• Universal Resource Identifier (URI): path and query elements that indicate the resource on which the action will be performed

• Request Headers: pieces of metadata that provide more information about the request itself or the requester

• Request Body: the data on which the service will perform an action

Web services that use these components to describe operations are often termed RESTful services, a categorization for services that use the HTTP protocol as it was originally intended.

Query interfaces

The Query interfaces offered by AWS also use the standard components of the HTTP protocol to represent API actions; however these interfaces use them in a different way. Query requests rely on parameters, simple name and value pairs, to express both the action the service will perform and the data the action will be performed on. When you are using a Query interface, the HTTP envelope serves merely as a way of delivering these parameters to the service.

To perform an operation with a Query interface, you can express the parameters in the URI of a GET request, or in the body of a POST request. The method component of the HTTP request merely indicates where in the message the parameters are expressed, while the URI may or may not indicate a resource to act upon.

These characteristics mean that the Query interfaces cannot be considered properly RESTful because they do not use the HTTP message components to fully describe API operations. Instead, the Query interfaces can be considered REST-like, because although they do things differently, they still only use standard HTTP message components to perform operations.

SOAP interfaces

The SOAP interfaces offered by AWS use XML documents to express the action that will be performed and the data that will be acted upon. These SOAP XML documents are constructed as another layer on top of the underlying HTTP request, such that all the information about the operation is moved out of the HTTP message and encapsulated in the SOAP message instead.

For operations performed with a SOAP interface, the HTTP components of the request message are nearly irrelevant: all that is important is the XML document sent to the service as the body of the request. The valid structure and content of SOAP messages are defined in a Web Service Description Language (WSDL) document that describes the operations the service can perform, and the structure of the input and output data documents the service understands. To create a client program for a SOAP interface, you will typically use a third-party tool to interpret the WSDL document and generate the client stub code necessary to interact with the service.

The approach used in the SOAP interfaces are very different from those used by the REST and Query interfaces. Operations expressed in SOAP messages are completely divorced from the underlying HTTP message used to transmit the request, and the HTTP message components, such as method and URI, reveal nothing about the operation being performed.

The main reason we eschew the SOAP interface in this book is because we believe that SOAP interfaces in general add unnecessary complexity and overhead, effectively spoiling the simplicity and transparency that can make web services such powerful and flexible tools.^[1] We are not alone in feeling this way. According to Amazon staff members, a vast majority of developers use the REST-based APIs to interact with AWS.

When a client performs an action using a REST-based interface, the messages are relatively simple. They can be constructed and interpreted by standard tools that recognize the HTTP protocol. SOAP messages, on the other hand, are much more complicated than those based on REST. To build a SOAP interface, you will generally require sophisticated tools to generate stub code before you can send any requests at all. Although such tools are readily available for some programming languages, typically those used in big business, they remain unavailable or immature on many platforms.

A secondary reason for avoiding SOAP is that we have tried to follow the KISS principle in this book. We have sought to keep our code samples as clear, simple, and broadly applicable as possible. Although most of our samples are written in the Ruby language, the techniques we demonstrate should be easy to apply in any other language that provides support for HTTP. If we presented SOAP interface clients, this code would demonstrate the subtleties of a particular third-party SOAP library much more effectively than it would the general-purpose techniques for using AWS that will work across multiple languages.

Note

The steps for using a service’s REST or Query interface will be very similar for the SOAP interface as well. As the different interfaces all look similar and act in much the same way, readers already familiar with SOAP, and with access to high-quality tools for interacting with SOAP services, should be able to follow along with our API discussions using the SOAP interfaces. However, be aware that the SOAP service interfaces do not always provide all the functionality available in the REST or Query interfaces.

---

^[1] The distinctions we allude to between different web service architectures are described in much more detail in RESTful Web Services by Leonard Richardson and Sam Ruby (O’Reilly). This book presents a strong case for avoiding the complexity that is SOAP, while discussing the theory and techniques necessary to build web services that take advantage of the simple, elegant, and efficient REST-based architecture that has served the Web so well.