REST API improvements

[kishansagathiya]

Inspired from discussions that happened in #634

• Support trailing slashes in URLs. That is, it should not redirect, but behave just the same way as URLs without a trailing slash(same response, same http code, no multiple requests or redirect)
• Errors returned by our APIs are in JSON format. Requests that doesn't reach our handlers and are responded by Gorilla are not in JSON format. Make sure that those responses are also in JSON format. So, when we fail to match a route instead of text message error not found 404, it should return a JSON response.
• Effects on tests. We have makePostWithContentType and other similar test helper functions, which should work for given content type judging them by their names, but there logic assumes that we are always using Content-Type as application/json. processResp and checkHeaders assumes that response should have. I don't see a point in having WithContentType functions when we know all responses should return json responses.
• Add tests for various APIs, make sure that trailing slash support is tested and returns JSON response. Test that APIs are not returning text error not found 404, but a JSON response.

Should be done after #634 is merged. #634 won't be perfect, but I think changes in this issue should make it so.

Thoughts?

[hsanjuan]

Inspired from discussions that happened in #634

* [ ]  Support trailing slashes in URLs. That is, it should not redirect, but behave just the same way as URLs without a trailing slash(same response, same http code, no multiple requests or redirect)

I wouldn't do this. Trailing slashes (and double //) are the wrong path. We can assume the user means to use a path without trailing slashes and //, but this is just an assumption (probably wrong in most cases as this is an API and such urls are just the result of bugs in clients). When gorilla enables the possibility of doing 308 redirects we can think of it as it would come for free, but right now things a better without any extra handling.

* [ ]  Errors returned by our APIs are in JSON format. Requests that doesn't reach our handlers and are responded by Gorilla are not in JSON format. Make sure that those responses are also in JSON format. So, when we fail to match a route instead of text message `error not found 404`, it should return a JSON response.

Yes, we can do this.

* [ ]  Effects on tests. We have `makePostWithContentType` and other similar test helper functions, which should work for given content type judging them by their names, but there logic assumes that we are always using Content-Type as `application/json`. `processResp` and `checkHeaders` assumes that response should have. I don't see a point in having `WithContentType` functions when we know all responses should return json responses.

ContentType different than json is used when using /add to make a multipart post.

* [ ]  Add tests for various APIs, make sure that trailing slash support is tested and returns JSON response. Test that APIs are not returning text `error not found 404`, but a JSON response.

Only a single test to detect that a catchall route returns 404 with the json message.

[kishansagathiya]

Currently makePost doesn't check http status code, in case the request succeeds. We should modify it to do so.

[hsanjuan]

It should probably return it, so it can be checked per test, when needed.

[hsanjuan]

The main actionable here is to make sure all errors are JSON (and test).