Parent issue: #141
It depends on: #143
We start building a new API using the /v2 prefix. For example: /v2/api/stats. We can use the same URLs but change the response codes.
Change the response codes to the right one: 200, 201, 404, etcetera. Right now, it only uses 200 and 500.
Potential changes
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 return "204 No Content".
- The
GET /api/whitelist/reload endpoint should be a POST, PUT or PATCH.
Notes
- We can keep the old API in parallel until we release the new major version.
Long-term changes
These are changes not included in this issue, but they should be considered in future versions.
- The
GET /api/whitelist/reload endpoint is a little weird. It's like a remote command. I think I should have used 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
- We could use a header parameter for the API version instead of a URL prefix, like this.
- Use a schema (most likely https://json-ld.org/).
- Re-design the API and consider other endpoints like the ones suggested here by @dev1z
Parent issue: #141
It depends on: #143
We start building a new API using the
/v2prefix. For example:/v2/api/stats. We can use the same URLs but change the response codes.Change the response codes to the right one: 200, 201, 404, etcetera. Right now, it only uses 200 and 500.
Potential changes
I think we could make other changes:
struct Unauthorized.routes.rs.authenticatefunction should also return a 401 response instead oftoken not validwhen the token is present but not valid.GET /api/torrent/:info_hashendpoint should return a 404 when the torrent does not exist and the token is valid.GET /api/torrent/:info_hashshould 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.DELETE /api/whitelist/:info_hashendpoint 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.POST /api/whitelist/:info_hashendpoint should return a "201 Created" response with the location of the new resourceGET /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 aPUT /api/whitelist/:info_hashto add a new torrent to the list.POST /api/key/:seconds_validendpoint should return a "201 Created".DELETE /api/key/:keyshould return "204 No Content".GET /api/whitelist/reloadendpoint should be aPOST,PUTorPATCH.Notes
Long-term changes
These are changes not included in this issue, but they should be considered in future versions.
GET /api/whitelist/reloadendpoint is a little weird. It's like a remote command. I think I should have usedPOST /api/commandswith the command you want to execute in the request body orPOST /api/reload-whitelist.GET /api/keys/reload