Spicy Spring: Customize error JSON response with ErrorAttributes

The default JSON error body of Spring Boot can be customized or extended by defining our own ErrorAttributes implementation. In Spring Boot we get an error response JSON format for free. Any thrown Exception is automatically translated to this JSON format and returned with a corresponding HTTP status.

Default implementation

As soon as we throw an Exception in a @RequestMapping annotated method of a @Controller, the thrown Exception is translated to a HTTP status and a JSON error body.

The default JSON error body looks like:

Write your own ErrorAttributes implementation

What if we want extra attributes in this JSON error body?

Just define an implementation for ErrorAttributes and register it as a Spring @Component. The following example will result in a customized JSON error response body with the cause of the exception included.

Our resulting body will now look like:

Happy developing!

Integration testing on REST urls with Spring Boot

We are building a Spring Boot application with a REST interface and at some point we wanted to test our REST interface, and if possible, integrate this testing with our regular unit tests. One way of doing this, would be to @Autowire our REST controllers and call our endpoints using that. However, this won’t give full converage, since it will skip things like JSON deserialisation and global exception handling. So the ideal situation for us would be to start our application when the unit test start, and close it again, after the last unit test.
It just so happens that Spring Boot does this all for us with one annotation: @IntegrationTest.
Here is an example implementation of an abstract class you can use for your unit-tests which will automatically start the application prior to starting your unit tests, caching it, and close it again at the end.

Grails Goodness: Using Converter Named Configurations with Default Renderers

Sometimes we want to support in our RESTful API a different level of detail in the output for the same resource. For example a default output with the basic fields and a more detailed output with all fields for a resource. The client of our API can then choose if the default or detailed output is needed. One of the ways to implement this in Grails is using converter named configurations.

Grails converters, like JSON and XML, support named configurations. First we need to register a named configuration with the converter. Then we can invoke the use method of the converter with the name of the configuration and a closure with statements to generate output. The code in the closure is executed in the context of the named configuration.

The default renderers in Grails, for example DefaultJsonRenderer, have a property namedConfiguration. The renderer will use the named configuration if the property is set to render the output in the context of the configured named configuration. Let’s configure the appropriate renderers and register named configurations to support the named configuration in the default renderers.

Continue reading

Grails Goodness: Custom Controller Class with Resource Annotation

In Grails we can apply the @Resource AST (Abstract Syntax Tree) annotation to a domain class. Grails will generate a complete new controller which by default extends grails.rest.RestfulController. We can use our own controller class that will be extended by the @Resource transformation. For example we might want to disable the delete action, but still want to use the @Resource transformation. We simply write a new RestfulController implementation and use the superClass attribute for the annotation to assign our custom controller as the value.

Continue reading

Grails Goodness: Change Response Formats in RestfulController

We can write a RESTful application with Grails and define our API in different ways. One of them is to subclass the grails.rest.RestfulController. The RestfulController already contains a lot of useful methods to work with resources. For example all CRUD methods (save/show/update/delete) are available and are mapped to the correct HTTP verbs using a URL mapping with the resource(s) attribute.

Continue reading

Grails Goodness: Enable Accept Header for User Agent Requests

Especially when we use Grails to create a RESTful API we want to enable the request header Accept, so Grails can do content negotiation based on the value in the header. For example we could use the request header Accept: application/json to get a JSON response. Grails will look at the boolean configuration property grails.mime.use.accept.header to see if the Accept header must be parsed. The default value is true so the Accept header is used. But there is another property which determines if the Accept header is used: grails.mime.disable.accept.header.userAgents. The value must contain a list or a regular expression pattern of user agents which are ignored for the Accept header. The default value is ~/(Gecko(?i)|WebKit(?i)|Presto(?i)|Trident(?i))/. So for any request from these user agents, mostly our web browser, the Accept header is ignored.

Continue reading

Grails Goodness: Customize Root Element Name Collections for XML Marshalling

When we convert a List or Set to XML using the Grails XML marshalling support the name of the root element is either <list> or <set>. We can change this name by extending the org.codehaus.groovy.grails.web.converters.marshaller.xml.CollectionMarshaller. We must override the method supports() to denote the type of collection we want to customize the root element name for. And we must override the method getElementName() which returns the actual name of the root element for the List or Set.

Continue reading