Manage web API error responses on the client side

[marco-brandizi]

This is a further split of the several issues raised by #377. Now the API manages exceptions occurring anywhere in the WS application in a uniform way, returning proper HTTP status codes together with a JSON document in the response body, which reports several details of what happened. This is an example of such JSON:

{
  "status" : 500,
  "detail": "<the whole stack trace>"
  "title": "Application error while running countHits: null",
  "statusReasonPhrase" : "Internal Server Error",
  "path" : "http://localhost:9090/ws/aratiny/countHits",
  "type" : "java.lang.RuntimeException"
}        

The format is based on the RFC-7807, which is a proposal to try to standardise REST error reporting. The code I wrote is an slight extension to the original proposal (it adds "statusReasonPhrase").

Here it is an example of how this is used by a Java client (look at testBadParametersCallError(), testBadCallError(), testForbiddenEx ()).

A Javascript handler should report the title field to the user (eg, the red alert next to the search keywords box) and other details (like the stack trace) in the Javascript console log.

[marco-brandizi]

@AjitPS, is this completed? Regarding #556, I'm seeing a pop-up message saying: A search error has ocurred: 500 ()

for a message on the server that actually says: java.lang.RuntimeException: Application error while running genome: null

Plus, I can't see anything on the Javascript console.

The point of the hereby enhancement should be telling the user something significant and making the developer able to understand a bit more without necessarily having to go to the server.

[marco-brandizi]

@AjitPS can this be closed? It would be good to console.log() the "detail" field in the response.

[AjitPS]

yes, all implemented now in UI msg and console with error detail, type and number

[marco-brandizi]

@AjitPS Maybe I'm missing something, but it doesn't seem the "detail" field (ie, the stacktrace) is logged.