Async REST calls with JAX-RS - rest

I need to create a RESTful service which should support async calls in follwing way. When user calls some method he got the http '202' code and url to poll where he can see the status of his request. Currently I use JAX-RS and its annoations:
#Path("")
public interface MyService {
#POST
#Path("/myService/{name}")
#Consumes({APPLICATION_XML, APPLICATION_JSON})
void postSomething(#PathParam("name") String name, MyObject data);
}
Such mapping would expose MyService's postSomething() method by url /myService/{name} which serves POST requests, get 'name' parameter from url and 'data' from request body.
I want that after making this PUT request client get 202 http code and some callback url to poll to get the result once method will be executed.
So the question is:
1. How to make JAX-RS return 202 code?
2. How to pass callback url to the client?

Have the postSomething method return a Response object:
public Response postSomething(#PathParam("name") String name, MyObject data) {
return Response.status(Status.ACCEPTED).build();
}
If you want the callback URI as plain-text in the HTTP Body you could do something like this:
public Response postSomething(#PathParam("name") String name, MyObject data) {
return Response.status(Status.ACCEPTED).entity("http://google.com").build();
}
For generating URIs by resource classes, have a look at UriBuilder

Use #Context HttpServletResponse servletResponse to get direct control over the servlet's response mechanism.
#PUT
#Path("/myService/{name}")
#Consumes({APPLICATION_XML, APPLICATION_JSON})
void postSomething(#PathParam("name") String name, #Context HttpServletResponse response, MyObject data) {
// ...
response.setStatus(HttpServletResponse.SC_ACCEPTED);
response.setHeader("Location", myURL);
// ...
}

Related

Adding headers to HTTP response when not returning a Response object in JAX-RS [duplicate]

This question already has answers here:
Set JAX-RS response headers in implementation without exposing HttpServletResponse in interface
(3 answers)
Closed 7 years ago.
I am creating a REST service using CXF 3.1.4 and JAX-RS. I have created an interface that is shared between client and server:
public interface SubscriptionsService {
#POST
#Path("/subscriptions")
SubscriptionResponse create(SubscriptionRequest request);
}
public class SubscriptionResponse {
private String location;
}
The client is created using JAXRSClientFactoryBean and the server is created using JAXRSServerFactoryBean.
The create() method defined above should return a Location header but I have no idea how to do it.
Since you need to return a SubscriptionResponse object instead of a Response object, you can inject the HttpServletResponse in your JAX-RS enpoint class using the Context annotation and set the 201 status code and the Location header:
#Context
HttpServletResponse response;
#POST
#Path("/subscriptions")
public SubscriptionResponse create(SubscriptionRequest subscriptionRequest) {
// Persist your subscripion to database
SubscriptionResponse subscriptionResponse = ...
URI createdUri = ...
// Set HTTP code to "201 Created" and set the Location header
response.setStatus(HttpServletResponse.SC_CREATED);
response.setHeader("Location", createdUri.toString());
return subscriptionResponse;
}
When returning a Response object, you can and use the Response API to add the Location header, as following:
#POST
#Path("/subscriptions")
public Response create(SubscriptionRequest subscriptionRequest) {
// Persist your subscripion to database
URI createdUri = ...
return Response.created(createdUri).build();
}
For more details have a look at the Response.created(URI) method documentation.

JAX-RS AsyncResponse.resume() with Location header

UPDATE
Some more digging showed that thrown Exceptions were dropped and the actual problem is that an injected UriInfo could not be resolved in the AsyncResponse's thread!
Accessing #Context UriInfo uriInfo; during AsyncResponse.resume() gives the following LoggableFailure's message:
Unable to find contextual data of type: javax.ws.rs.core.UriInfo
ORIGINAL
According to RFC 7231 HTTP/1.1 Semantics and Control, a POSTshould return 201 CREATED and supply the new resource's location in the header:
the origin server
SHOULD send a 201 (Created) response containing a Location header
field that provides an identifier for the primary resource created
(Section 7.1.2) and a representation that describes the status of the
request while referring to the new resource(s).
When writing a synchronous REST Server, the javax.ws.rs.core.Responseoffers the Response.created() shorthand which does exactly that.
I would save the new entity, build an URI and return
return Response.created(createURL(created)).build();
However, when I switch to an asynchronous approach utilizing a
#Suspended javax.ws.rs.container.AsyncResponse
the HTTP request on the client will hang infinitely:
#POST
public void createUser(#Valid User user, #Suspended AsyncResponse asyncResponse) {
executorService.submit(() -> {
User created = userService.create(user);
asyncResponse.resume(
Response.created(createURL(created)).build()
);
});
}
Through trial-and-error I found out that the modified location header is responsible.
If I return my entity and set the 201 Created, without touching the header, the request will eventually resolve:
#POST
public void createUser(#Valid User user, #Suspended AsyncResponse asyncResponse) {
executorService.submit(() -> {
User created = userService.create(user);
asyncResponse.resume(
Response.status(Status.CREATED).entity(created).build() //this works
//Response.created(createURL(created)).build()
);
});
}
So what's the problem? Am I misunderstanding the concepts?
I am running RestEasy on GlassFish4.1
If you need more information, please comment!
edit
As soon as I change any link or the header, the request will hang.
In case anyone ever has the same problem:
The problem was that I created the location header through an injected #Context UriInfo uriInfo using its .getAbsolutePathBuilder().
The approach was working in a synchronous server because the thread which accessed the UriInfo still had the same Request context.
However, when I switched to an async approach, the underlying Runnable which eventually had to access uriInfo.getAbsolutePathBuilder() was NOT within any context - thus throwing an exception which halted further execution.
The workaround:
In any async method which should return a location header, I .getAbsolutePathBuilder() while still within the context. The UriBuilder implemantion can then be used within the async run:
#POST
public void createUser(#Valid User user, #Suspended AsyncResponse asyncResponse) {
UriBuilder ub = uriInfo.getAbsolutePathBuilder();
executorService.submit(() -> {
User created = userService.create(user);
asyncResponse.resume(
Response.created(createURL(ub, created)).build()
);
});
}
private URI createURL(UriBuilder builder, ApiRepresentation entity) {
return builder.path(entity.getId().toString()).build();
}

#BeanParam gives exception A message body reader for Java class was not found

I am trying to make a jersey based web service. In this if i take input params using #FormParam it works fine:
#POST
#Consumes({MediaType.TEXT_PLAIN, MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON, MediaType.TEXT_HTML, "application/x-www-form-urlencoded"})
#Path("/registeruser")
public Response registerUser(#FormParam ("email") String email,#FormParam ("name") String name ){
System.out.println("Inside register device");
System.out.println("registered" + email);
return null;
}
but when I try using #BeanParam it does not works and gives me an exception
#POST
#Consumes({MediaType.TEXT_PLAIN, MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON, MediaType.TEXT_HTML, "application/x-www-form-urlencoded"})
#Path("/registeruser")
public Response registerUser(#BeanParam UserForm userForm ){
System.out.println("Inside register device");
service.registerUser(userForm);
System.out.println("registered" + userForm.getEmail());
return null;
}
A message body reader for Java class com.stc.dms.forms.UserForm, and Java type class com.stc.dms.forms.UserForm, and MIME media type application/octet-stream was not found.
You don't need to use #BeanParam to pass an object as input. Just pass it like this :
#POST
#Path("register")
#Consumes(MediaType.APPLICATION_JSON)
public Response registerUser(UserForm dto) {
// ...
}
Just make sure to include the libraries for producing/consuming json. If the client is in javascript you don't need anything else (just use JSON.stringify() on your form object), for the server add some json libraries such as Jackson
EDIT :
If you want to stick with #BeanParam, take a look at this tutorial here. Basically it seems that you don't need to specify the mediatype, as Jersey will handle that for you.

How to handle requests with unsupported content type correctly?

I have a REST interface build with Jersey. Actually I only support as content type only application/json for all incoming requests. That is why I defined my message body reader and writer as
#Provider
#Consumes(MediaType.APPLICATION_JSON)
#Produces(MediaType.APPLICATION_JSON)
public class MarshallerProvider
implements MessageBodyReader<Object>, MessageBodyWriter<Object>
{
}
Now I wrote a test where I try to get a document via GET and expected content type application/xml. Jersey answers this request with an MessageBodyProviderNotFoundException.
So what would be the best way to handle such unsupported requests correctly? Should I write an exception mapper? Since it is an internal exception I don't like this approach?
The solution should allow me to return an HTTP 415 (Unsupported Media Type).
Yes, avoid exception handlers, handle this case with methods:
#Path("example")
public class Example {
#GET
public Response getBadStuff() {
return Response.status(Response.Status.UNSUPPORTED_MEDIA_TYPE).build();
}
#GET
#Produces(MediaType.APPLICATION_JSON)
public Object getGoodStuff() {
return myObject;
}
}

Spring MVC GET/redirect/POST

Say I have 2 Spring MVC services:
#RequestMapping(value = "/firstMethod/{param}", method = RequestMethod.GET)
public String firstMethod(#PathVariable String param) {
// ...
// somehow add a POST param
return "redirect:/secondMethod";
}
#RequestMapping(value = "/secondMethod", method = RequestMethod.POST)
public String secondMethod(#RequestParam String param) {
// ...
return "mypage";
}
Could redirect the first method call to second(POST) method?
Using second method as GET or using session is undesirable.
Thanks for your responses!
You should not redirect a HTTP GET to a HTTP POST. HTTP GET and HTTP POST are two different things. They are expected to behave very differently (GET is safe, idempotent and cacheable. POST is idempotent). For more see for example HTTP GET and POST semantics and limitations or http://www.w3schools.com/tags/ref_httpmethods.asp.
What you can do is this: annotate secondMethod also with RequestMethod.GET. Then you should be able to make the desired redirect.
#RequestMapping(value = "/secondMethod", method = {RequestMethod.GET, RequestMethod.POST})
public String secondMethod(#RequestParam String param) {
...
}
But be aware that secondMethod can then be called through HTTP GET requests.