The latest version of Jakarta REST (formerly Java API for RESTful Web Services, aka JAX-RS), Jakarta REST 4.0, will bring some notable improvements and changes as part of Jakarta EE 11. This release focuses on modernizing the specification by removing legacy dependencies, enhancing developer convenience, and improving test coverage. Before exploring the key changes, let's first take 37K feet intro to JAX-RS for the new comers to the platform. 

Creating scalable and flexible APIs is essential for today's web applications. When it comes to RESTful APIs in enterprise Java/Jakarta EE software development, one concept that plays a crucial role in driving adaptability, discoverability and evolvability is Hypermedia as the Engine of Application State (HATEOAS). In effect, the HATEOAS principle can help developers to significantly enhance their API designs, making them more powerful and futureproof.

Our latest guide on HATEOAS is specifically designed for developers familiar with RESTful API development using Jakarta REST (formerly known as JAX-RS). In this blog post, we’ll explore the key takeaways from the guide and show you how mastering HATEOAS can transform the way you build and evolve your APIs.

Speed and responsiveness are very important in the development and use of modern RESTful APIs in Java applications, as they help ensure efficiency and scalability, especially as businesses move towards cloud-native applications. The primary means of achieving high speed, responsiveness, efficiency and scalability is through asynchronous processing. It allows applications to handle requests efficiently and perform tasks without getting stuck, making things run smoother and faster for the user while supporting scalability.

In this post, we'll look at how asynchronous processing works in Jakarta RESTful Web Services (JAX-RS or Jakarta REST) and how to implement async patterns in JAX-RS to enhance your Java web services, so you can build powerful and scalable RESTful APIs in Java.

Welcome to this week’s Friday Nugget and congratulations, you've made it through the week! What better way to kick off the weekend than by talking about simplifying something that is essential to ensure that data flows smoothly between clients and servers, meeting all necessary formats, types and rules. Correct, we are talking about validation.

REST, or Representational State Transfer, is the web standard for building APIs and applications. It offers a lightweight architecture for exchanging data between applications over the web. Jakarta REST (formerly JAX-RS) is the standard API for building RESTful web services on the Jakarta EE Platform. 

This blog post looks at caching within Jakarta REST. We'll explore how to use the built-in features and functionalities to enhance the performance and user experience of your RESTful APIs through resource caching. By using these techniques, you can significantly reduce server load, improve responsiveness, and enhance the overall efficiency of your web resources.

Oftentimes in a Jakarta REST application, you may need to access some metadata about a given resource method matched by the Jakarta REST runtime, outside of a resource class. This could be so as to dynamically alter the client's request based on some custom business requirement, or for informative purposes. For example, in a Jakarta REST component like an exception mapper, you might want to get the currently matched resource method and get its HTTP method. 

Oftentimes in web applications, there is the need to intercept a request from the client to resource methods. Sometimes this interception must take place even before the request is matched to a resource method. For such needs, Jakarta REST provides the jakarta.ws.rs.container.ContainerRequestFilter interface. This interface is a Jakarta REST extension that can be used to intercept requests to resource methods. 

An implementation of this interface can decide if requests should be intercepted before they’re matched to resource methods through the @PreMatching annotation. A pre-matched request filter will be invoked by the container before the request is matched to its intended resource method. 

For this blog post, let us look at two use cases for request filters. One is a situation where for security reasons, certain HTTP methods are not allowed. For example an organisation can have a security rule in its firewall that disallows HTTP PUT methods. In this case, either all methods have to be POST or request filters can be used to workaround the restriction. 

The second situation is for the custom implementation of authentication. Of course you absolutely should NOT hand-roll your own security setup unless you know in detail exactly what you are doing. You are better off using tried and tested security frameworks and services out there. But for this blog post, assuming we need to implement custom security, we can use a pre matching request filter. The following code snippet below shows a ContainerRequestFilter implementation that implements the two scenarios above.

Java generics is a great feature that allows you to have compile time checks for generics. However, due to historical reasons of backward compatibility, type information for generics is erased at runtime. A lot of the time this shouldn’t be of much concern. But there are a few cases where type information is needed at runtime for some kind of decision. 

One such situation is in Jakarta REST when the jakarta.ws.rs.core.Response object is used to return a generic collection of a specific type. For example the code below shows the creation and return of a Response object that has a list of HelloEntity as the return payload to the client. 

All non-trivial enterprise applications have some sort of constraints on the data the application processes. These constraints could range from the simplest to the most complex custom built types. The default validation API on theJakarta EEPlatform, Jakarta Bean Validation has excellent out of the box support for constraining bean fields. Then with its @Valid annotation, you can trigger automatic validation of constrained objects in certain points of an application.