Spring Boot response compression

If Spring Boot app produces response (like json, xml) which is huge in size, gzip compression is a simple way to reduce latency and bandwidth. Gzip is used for file compression and decompression. These days processing time is cheap (multi-core CPU's are commonplace) while bandwidth is expensive.

If the SpringBoot app is using embedded tomcat, gzip can be enabled using simple configurations

In case of application.properties include:

server.compression.enabled=true
server.compression.mime-types=application/json,application/xml,text/html,text/xml,text/plain

In case of application.yml include:

 server: 
   compression: 
     enabled: true
     mime-types: application/json

For compressed response to work, clients calling the endpoint has to accept gzip encoded response. Clients using Spring RestTemplate need not do anything specific, RestTemplate supports gzip compression by default. In case of curl following command can be used to check compressed response size.

curl --compressed -H "content-type:application/json" -X POST URL -w "size: %{size_download}\n" 
Note: Compressed HTTP header request compressed content, if the server can provide it]

I have tried above configuration in SpringBoot v1.3.5.RELEASE

REST applications: Identifying resources

One of the first step in designing a REST application is to identify resources and define their representation. Oft heard advice in this regard is "nouns are your resources". Go through your application and its requirement/use cases, identify all the nouns, model them as resources and use HTTP verbs on these resources to add their operations. GET is to get the resource, PUT is to modify the resource, DELETE is to delete the resource while POST is to be used to create a new resource.

However, this only serves to arrive at the 1st set of resources. It has to go through multiple iterations wherein this initial resource set is refined to add/prune/modify to arrive at the final list of resource. Often it helps to run the list through a few questions.

Which resources are important from client's point of view ? All nouns or entities that are used internally inside  an application behind the scene may not be relevant to clients and so shouldn't be part of resource list. At the same time there would be a number of not-so-obvious resources. Some applications may like to expose some derived information to client as web services,  an example would a valuation calculator that provides calculations like average,standard deviation, percentage against ceiling or floor values. Thus "ValuationCalculator" can be modeled as a resource.

Can all actions/operations be handled by using HTTP verbs on existing resources ? For example in a banking application how to handle an AccountTransfer operation wherein an account is transfer from one branch to another. As this operation involves changing the representation of Account resource, we can add an attribute branch to Account resource ( this attribute can be an URI of Branch resource). Then we can apply PUT verb on Account resource to implement AccountTranfer operation.

However some other actions are more tricky to handle. For example - processing of account opening  application in a banking application. Which resource should handle this operation - Account, Customer, Branch. Herein, we need to introduce a new resource - AccountApplication which will have an status (with possible values of approved, declined, under process, on hold etc.)  attribute in its representation. Thus as the application goes through varied approval processing, PUT verb can be applied on AccountApplication resource to keep track of status.