The Major Communication Standards for AWS

To interact with AWS in any meaningful way, you must communicate with it. Communication occurs at several levels, which include:

• Transport: This is the underlying layer that actually transfers the data between parties.
• Discovery: To interact with AWS, you need to know which methods are available. The discovery level allows you to use a common URL to request the list of available methods for a particular service in either XML or JSON as a list of hyperlinks.
• Request: After you know which methods are available, you can make a request, and AWS provides a response.

You can easily break communication into more layers, but these layers represent the most basic and essential breakdown. Understanding these layers is enough to write robust applications using AWS. (As your applications become larger and more complex, and AWS adds more functionality, you may need to work with additional layers.)

Transporting the data

The first communication concern you must address is the matter of transport. AWS supports HTTP for nonsecure requests and HTTPS for secure requests for some services, including those in the following list:

• Amazon Associates Web Service
• Amazon CloudFront (HTTPS is required for the control API; currently only HTTP is accepted for the request API)
• Amazon DevPay (HTTPS is required for the License Service)
• Amazon Elastic Compute Cloud
• Amazon Flexible Payments Service (HTTPS is required)
• Amazon Fulfillment Web Service (HTTPS is required)
• Amazon Mechanical Turk
• Amazon SimpleDB
• Amazon Simple Queue Service
• Amazon Simple Storage Service

In most cases, using Secure Sockets Layer (SSL) in the form of HTTPS requests produces the best result because the information remains secure over the Internet. If the data you need isn’t confidential in nature, you can sometimes achieve better application speed using HTTP instead. In some cases, you must use HTTP because the service doesn’t support HTTPS, so be sure to check the service documentation before you make any assumptions.

Most developers know about both HTTP and HTTPS through desktop and browser application development. However, what you might not know is that AWS also supports Message Queuing Telemetry Transport (MQTT). This publish/subscribe messaging transport protocol addresses the needs of constrained devices, such as those used to perform the Internet of Things (IoT) and Machine-to-Machine (M2M) tasks. Check out more information about MQTT at and the AWS view of it. AWS allows use of MQTT with a number of services, including

• Amazon Simple Storage Service
• Amazon DynamoDB
• Amazon Kinesis
• AWS Lambda
• Amazon Simple Notification Service
• Amazon Simple Queue Service

Obtaining an API method listing

Before you can do anything with AWS, you need to know which tasks (accessible using methods) are available. The API documentation can provide you with an overview of what you can do, but the actual list of available methods is flexible and varies by context. For example, you may not be able to perform certain tasks with some services because you lack a secure connection or you haven’t configured the service to support the desired task.

One of the reasons that you want to use REST is that it doesn’t map Create, Read, Update, and Delete (CRUD) requests directly to the HTTP as a protocol does (creating an unbreakable contract that you must modify every time you need to make a change). You make a request using a standard URL with a GET request and receive a list of hypermedia links to the actual method calls. The article on Hypermedia as the Engine of Application State (HATEOAS) describes how this process works in more detail.

Originally, REST relied on XML to provide the list of links to specific method calls, but using Hypermedia Access Language (HAL) enables you to use JSON instead, which is easier to understand. AWS currently relies on XML for any sort of API query because most developers seem to understand XML better. is the native format for AWS. This article at provides details on the REST API.

At one time, AWS provided extensive support for the Simple Object Access Protocol (SOAP). In fact, you can still use SOAP to make requests, but only by using HTTPS. In other cases, AWS no longer supports SOAP at all (an example of deprecation for the EC2 service).

Making a request

Requests and responses follow the familiar patterns used with other web services. However, AWS is careful to ensure that you know that REST is merely the architecture and that API requests add something to REST; that is, they represent a different layer. In many cases, you see REST/query, which refers to REST used with an API call of some type.

You must sign most REST requests you make to AWS. Some services, such as Simple Storage Service (S3), allow anonymous requests. To garner any significant amount of information, however, you must provide signed (authenticated) requests. However, this article describes how to use such a request to fix a security problem with an S3 bucket.

When making a request using the CLI or an SDK, the environment signs your request for you. Even though the request is still signed, you don’t need to worry about performing the task manually. You can read more about signing particulars at.