Exercise Tracker API is not RESTful

The exercise tracker’s API, as described on the GitHub repo, is not RESTful. I’m happy to submit a fix for this myself, but I believe these microservice challenges use some automated tests, so I thought it would be best to track the issue here until we’re in a good spot for breaking changes. If we only need to change the project’s documentation and the example’s endpoints then this will be easy.

https://github.com/freeCodeCamp/boilerplate-project-exercisetracker/

Current API

POST /api/exercise/new-user - “new-user” isn’t a resource. Better to stick with “users” as the resource and let the HTTP define new-ness. GET /api/exercise/users POST /api/exercise/add - RESTful APIs should avoid using verbs in the path GET /api/exercise/log - This is awkward as “log” is also a verb. Also, we’re really getting a log from the user resource, so why not make that clear in the URL?

All of the endpoints exist under /api/exercise, which implies a strange hierarchy of users and user logs being properties of an exercise, which is not right.

Proposal

GET /api/users - Returns all users POST /api/users - Creates a new user GET /api/users/{user_id}/logs?[from][to][limit] - Returns all exercises entered for the specified user POST /api/users/{user_id}/exercises - Logs a new exercise to the specified user

[ProfessorSalty]

I believe this was done so that someone could have all these APIs running on a single domain without potential conflicts.

That’s a point I hadn’t considered. IMHO, it would make more sense to scope the /api endpoints to each project rather than the other way around, eg. exercise/api/..., timestamp/api/.... This would be clearer in intent and even allow students to serve clients in the base URL (excerise/public, for example) or pull the API code into a separate application easily.

is this opinion based or best practice (i.e. referenced somewhere that RESTful should not use verbs)?

I wish I had some text to point to as gospel. Really, this is my opinion based on my understanding of RESTful architecture. I’m certainly fallible - I would even say error prone - but I’m confident in my case here even if I can’t point to why.

[RandellDawson]

I like the idea of /api/timestamp/[date] because as was mentioned by @scissorsneedfoodtoo, a single domain could house multiple APIs.