Chapter 6. Working with the DynamoDB API

In the previous chapter, we saw how to perform query and scan operations on DynamoDB table items using a table and its index. We also discussed parallel scanning. Most of our discussion was done using Java SDK because of the Java language's strengths. In order to perform the query and scan operations, we need to download or install certain packages onto our PC. Yet, there is a way to perform DynamoDB operations through an HTTP request. So, similar to accessing the management console, these HTTP requests to access DynamoDB are also performed through a web browser.

In this chapter, we will discuss the following topics:

• Data format

• HTTP requests

• Error handling

• Operations in DynamoDB

As part of our discussion in this chapter, we will learn about all of these topics. Before this, we should have our security credentials in hand, which we can fetch from the security page in the management console.

Data format

DynamoDB uses the JavaScript Object Notation (JSON) format to send the request to, and receive the response from, the DynamoDB endpoint. One important rule of thumb is that the DynamoDB endpoint gets this JSON request and parses it into its native format (which is not JSON). During this time, some data loss might occur because of compatibility issues. For example, JSON supports the date data type, but DynamoDB does not support it. So the JSON request should not have a DynamoDB incompatible data type. In order to avoid this situation, DynamoDB has already listed the allowed data types, and they are as follows:

• S: This denotes the String data type to store strings such as "Kuppu"

• N: This denotes the Number data type to store numbers such as 2014

• B: This denotes the Binary data type

• SS: This denotes the StringSet data type to store string sets such as {"Uchit", "Vyas"}

• NS: This denotes the NumberSet data type to store number sets such as {2013, 2014}

• BS: This denotes the BinarySet...

HTTP requests

As discussed in the previous section, only the request and response is in JSON format. On both the client side and the server side, this JSON data (request and response) is parsed by the SDK or the browser (on the client side) and DynamoDB (on the server side).We can perform almost all types of DynamoDB operations through HTTP requests. All the possible operations are listed, and we will discuss them in detail in the last section of this chapter. Now, let's observe the HTTP request structure. The strength of the REST API can be easily understood from the fact that most of the SDKs use REST API internally for all their calls.

Here, I have used Postman (an extension of Google Chrome) to perform the REST operations. Other than that, many other software options, such as cURL, are also available for the same purpose.

In the following screenshot, we need to understand the use of the three sections (on the right-hand side):

The first section has a textbox, a drop-down menu (with POST...

Error handling

As discussed in the previous section, DynamoDB responds with three kinds of status codes. Response 200 means success; responses starting with 4 (400, 413, and so on) are client-side errors caused by syntax error, and responses starting with 5 (500) are server-side errors, caused because the provisioned throughput has been exceeded, the service is down, and so on.

Along with this status code, every error has an error message too. For example, a request with an invalid signature will result in a 400 error code, with the com.amazon.coral.service#InvalidSignatureException exception with the error message "The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.".

Let's see what all the possible client-side errors are. There are only two client-side status error codes. These are 400 and 413. Out of these client-side errors, a few are timing errors only. If we...

Operations in DynamoDB

The DynamoDB REST API supports almost all the possible operations that are supported by the SDK and the management console. The possible operations are:

• CreateTable

• PutItem

• UpdateItem

• GetItem

• Query

• Scan

• DeleteItem

• DescribeTable

• UpdateTable

• DeleteTable

• ListTables

• BatchGetItem

• BatchWriteItem

For all of these operations, only two things will change. The first is the request body and the second is x-amz-target, which specifies what kind of table operation has to be performed. This attribute is the same as that of the name of the operation as shown in the previous bullet list. For example, to perform the DescribeTable operation, x-amz-target is DynamoDB_20120810.DescribeTable itself, so we will not be explaining it in the following text.

CreateTable

To perform the CreateTable operation, the request JSON will look as follows:

{
  "AttributeDefinitions": [
    { "AttributeName": "BookTitle", "AttributeType": "S" },
    { "AttributeName": "Author", "AttributeType...

Summary

In this chapter, we have learned how to use the REST API to perform DynamoDB operations. We have also learned about a few things that we never came across in previous chapters (take BatchWriteItem and BatchGetItem for instance). The usage of batch operations will provide the output in a faster way, because all table data is queried or written in parallel. One tradeoff is that it consumes a lot of capacity units. In simple words, using the batch operation will give you an optimized result, but you might have to pay more.

In the next chapter, we will learn about the distributed locking used in DynamoDB for transaction management. In the case of multitenant systems, this locking mechanism is pretty important because of batch operations and because multiple users might write or read data simultaneously. Without implementing locking techniques in our application, we will always get unacceptable responses and the application will nosedive. We will also see the Java high-level API for DynamoDB...