The other day I had a discussion with the team regarding an API design. We designed Web API endpoints to manage "self-service" functionalities. Basically, we need APIs to allow front end applications to call our API to manage the current user. From the endpoint perspective, there are two options.

Implicit. The API implementation will figure out the current user from login token (WKT token). The endpoint might look like this

/self-service/update-info

Explicit. The endpoint needs to carry the user id. And the implementation must ensure that it matches with the current user id from the login token. The endpoint might look like this

/{userId}/self-service/update-info

There are pros and cons of each approach. In the API design, there is no right or wrong anwser.
The implicit approach is simple. But it is hard to extend and there are assumptions. The biggest one is that only logged in user can update their information. Which might be a strict and value rule in some application.

The explicit approach is a bit more complex because consumers must pass the user id and the implementation must guard the correct id with logged in user. The benefit comes when we need to support this case "Administrators can update user information." Which is also a possible valid user case.

API is contract. It is hard to change. You need to communicate with all consumers. Implementation detail is easier to change as long as the API behavior is unchanged.

The principle: API design should cover as many possible scenarios as possible as long as the API signature is clean and clear. The implementation detail can restrict to support certain behavior. In other words, the implementation is a subset of the API.

A common mistake is designing API base on the implementation detail.