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?

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.