With my very simple JAX-RS service I'm using Tomcat with JDBC realm for authentication, therefore I'm working the the JSR 250 annotations.
The thing is that I want to return a custom message body in the HTTP status response. The status code (403) should stay the same. For example, my service looks like the following:
@RolesAllowed({ "ADMIN" })
@Path("/users")
public class UsersService {
@GET
@Produces(MediaType.TEXT_PLAIN)
@Consumes({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
public String getUsers() {
// get users ...
return ...;
}
}
If a user with a different role than "ADMIN" access the service, I want to change the response message to something like that (depending on the media type [xml/json]):
<error id="100">
<message>Not allowed.</message>
</error>
At the moment Jersey returns the following body:
HTTP Status 403 - Forbidden
type Status report
message Forbidden
description Access to the specified resource (Forbidden) has been forbidden.
Apache Tomcat/7.0.12
How can I change the default message body? Is there a way to handle the (maybe thrown) exception to build my own HTTP status response?
REST is build upon HTTP so you don't have to change the default behavior of an authentication failure. Having a 403 error when accessing a resource is enough for the client to clearly understand what appends.
The more your resources are HTTP compliant, the more others can understand it.
With creating an
ExceptionMapper
(mapping exceptions ofWebApplicationException
) it is possible to "catch" certain exceptions thrown by the application:You also need to add the package to your application web.xml for registering the provider:
The easiest way to handle this sort of thing is to throw an exception and to register an exception mapper to convert into the kind of message you want to send in that case. So, suppose you throw an
AccessDeniedException
, you would then have a handler like this (with full class names in places for clarity):The way in which you register the exception mapper varies according to the framework you're using, but for Jersey you should be fine with just using
@Provider
. I'll let you figure out for yourself how you want to generate the kind of error documents that you want, but I do recommend handling failures as HTTP error codes of some kind (that's more RESTful...)