The API returned a 500 code when the token was missing. I've changed it, and now it returns a 401 code. The change affects all endpoints.

I think we could make other changes:

• Refactor: create a custom Reject for all the errors. Like the one I have added: struct Unauthorized.
• Refactor: move routes to their own mod routes.rs.
• The authenticate function should also return a 401 response instead of token not valid when the token is present but not valid.
• The GET /api/torrent/:info_hash endpoint should return a 404 when the torrent does not exist and the token is valid.
• The endpoint GET /api/torrent/:info_hash should return a 404 when the torrent does not exist and the token is invalid. See Insecure Direct Object References (IDOR)). We should not expose that the tracker has a given torrent because the tracker could be private.
• The DELETE /api/whitelist/:info_hash endpoint should return: a "204 No Content" when it deletes the torrent and a "404 Not Found" when the torrent does not exist or the token is invalid.
• The POST /api/whitelist/:info_hash endpoint should return a "201 Created" response with the location of the new resource GET /api/whitelist/:info_hash. In this case we would need to create that new endpoint. It could be empty. It could be used only to know if a torrent is whitelisted. Alternatively, we could consider the whitelist a unique resource and use a PUT /api/whitelist/:info_hash to add a new torrent to the list.
• The POST /api/key/:seconds_valid endpoint should return a "201 Created".
• The DELETE /api/key/:key should should return "204 No Content".
• The GET /api/whitelist/reload endpoint should be a POST, PUT or PATCH. This endpoint is a little weird, it's like a remote command. I think I should have use POST /api/commands with the command you want to execute in the request body or POST /api/reload-whitelist.
• Same for GET /api/keys/reload

@WarmBeer @da2ce7 do you think those changes make sense? If you do, should I make them now or postpone them?