Now that we have a basic API Gateway endpoint and Lambda function, the next meaningful step is to save the data posted to the API. Keeping with the AWS serverless theme, in this article we will add persistence with the help of DynamoDB. We will also keep things automated by continuing to utilize the AWS Serverless Application Model (SAM).

If you look closely, yes, there are certainly servers running our serverless applications in the cloud. However, the serverless approach and the platforms that enable it provide impressive capabilities without requiring us to manage the server environment. In this post I will begin developing a basic REST API with a serverless approach on AWS, starting with Lambda and API Gateway.

Some say that all good things must come to an end. While this exploration of the DELETE method marks the end of this article series, you’ll see that deletion is not necessarily the end of life for the data items backing your REST API.

When the time comes to handle data updates via a REST API, we may have a choice to make. The list of HTTP verbs, which are the basis for REST operations, includes both PUT and PATCH. Each of these provide a way to update existing resources, and we will cover both in this article.

Wiring up a controller method to support POST requests isn’t all that different from setting up a GET handler. However, taking data in to our API raises new considerations. How do we make sure the input meets our quality standards? How do we handle the fields required in our data layer that are not provided by the input object?

In the previous article in this series, we created some GET methods on our @RestController and we tested these methods by calling them in Postman and reviewing the results. We must be done, right?

We will start with the humble GET request, but before we can expose our data to the world we need somewhere to write that code. We need a @RestController. The controller is fundamental to Spring MVC, both in web applications and a REST API like we’re building here. This is where we define our specific HTTP endpoints and the corresponding methods to handle requests.

API development with a REST approach is a widely used standard for providing application functionality over a network. Spring Boot provides robust capabilities for implementing your API, and this blog series will provide a solid introduction to developing and testing a REST API with Spring Boot.

Here we have two type names that seem awfully similar: Comparable<T> and Comparator<T>. How do they relate? When would we use one versus the other in our Java code?

While working through the Spring Security aspects of my SpringBikeClinic.com project, I implemented SecurityUser, a custom UserDetails object which was composed with a User database entity. For unit testing my @Controller code, I wanted a clean way to provide a mock instance of my custom user type.