Igor Kromin |   Consultant. Coder. Blogger. Tinkerer. Gamer.

This is a follow on article from Jersey JAX-RS filters and interceptors execution order for a simple GET request. This time instead of a GET request I'll be looking at a POST request.

For the sake of brevity this article builds on top of the classes already created in the earlier article and also makes use of the classes from this article - Writing a custom MessageBodyReader to process POST body data with Jersey. Please review both of these articles first if you haven't already done so.

Making a POST request to the /hello URI ends up executing the following filters and interceptors...
jerseyflow__post1.png


It's mostly the same as the execution flow for a GET request, except prior to the resource class being called there are calls to the reader interceptor and then the message body reader classes. After the resource class is run, the execution order remains the same as for a GET request.

Now what if instead of using a custom message body reader we used a standard @FormParam annotation to pass a value to the resource? Here's a new resource class that implements just that...
 Java
@Path("/hello2")
@Produces({ "text/plain" })
public class HelloPostResource2 {
@POST
@Consumes("application/x-www-form-urlencoded")
public String sayHello(@FormParam("name") String name)
{
Logger.getLogger("net.igorkromin.Logger")
.debug(">>> MyResource 2");
return "Hello " + name;
}
}




This class has a @Consumes("application/x-www-form-urlencoded") annotation on the @POST method to specify that form data is being expected. The parameter to the sayHello() method is now annotated with @FormParam and is changed to a simple String data type. The path is changed to /hello2.

Sending a POST request to the /path2 URI produces the following execution order...
jerseyflow__post2.png


As expected the message body reader is not called at all, but the reader interceptor is. This is because the message body reader that was created for the first POST resource doesn't match for the new resource and hence never gets executed.

That sums up how a POST request is processed in a standard use case. I'll be following up soon with an article on what happens during cases where an exception is thrown. Keep an eye out for future posts, I'll link them here as they are available.

-i

Please leave your comments or feedback below!
comments powered by Disqus
Other posts you may like...
Hi! You can search my blog here ⤵
Or browse the recent top tags...

Recent Blog Posts

Using DeoxIT to repair old game catridges

WebLogic Maven Plugin - How to fix the MojoExecutionException: The artifact location was not specified

jPhotoFrame version 0.4 released with a whole new layout engine

Upcycling a couple of old broken lamps to create something amazing

A custom exception mapper and writer for a RESTful JAX-RS Jersey service

How to fix Plex error - Sorry there was a problem playing this item

Jersey JAX-RS filters and interceptors execution order for a POST request

Fix your Mac - users not showing on the macOS login screen when FileVault is enabled

BMB-012 Nanoblock T-Rex Skeleton Model assembly

Writing a custom MessageBodyReader to process POST body data with Jersey

Recent Galleries

BMB-012 Nanoblock T-Rex Skeleton Model assembly

Tiny Arcade revision 6 kit assembly and decal application

Atari Lynx repair - Part 5 - McWill LED screen mod installation

Atari Lynx repair - Part 4 - screen cover replacement

Atari Lynx repair - Part 2 - re-capping the motherboard

Atari Lynx repair - Part 3 - broken speaker replacement

Atari Lynx repair - Part 1 - introduction and case disassembly

Building a custom Atari Lynx game box storage shelf unit in a day

Protecting old Atari Lynx game boxes with snug fit plastic sleeves

Monument Valley 2 is released and does not disappoint

Blogs and Friends

Matt Moores Blog
Georgi's FlatPress Guide
Perplexing Permutations
The Security Sleuth
Ilia Rogatchevski
Travelling Fairy

Blog Activity

Blog Activity