One of the key principles of REST is the concealment of the server's resource implementation behind a standard interface. Essentially, it should be difficult to discern from the resource identifiers whether you are dealing with "relational data".
On one hand, this offers freedom in designing the most suitable resource model for your requirements; on the other hand, it can lead to overthinking due to the abundance of options available.
POST /api/users/resource
POST /api/resource
Both options are acceptable. Machines can handle either message without issue. In fact, creating an API that caters to both scenarios would also work just fine.
So how do we make a decision?
The answer has two components. The first involves understanding resources, which are essentially abstractions of documents. When requesting a document on the web, one possibility is that the document may be cached. If sending a message intended to modify a document, it's vital to invalidate previously cached versions of that document.
The URI serves as the primary identifier for cached documents.
In the scenario where a message is sent to the server to store a new document and the server is expected to assign its own identifier to the copy, targeting the resource serving as the index of documents on the server makes logical sense.
This explains why CreateItem operations are typically implemented as POST handlers on a Collection resource - if an item is successfully added, cached responses to GET /collection should be invalidated.
Is this the only way to approach it? No, it's a matter of considering trade-offs and choosing one option. Opting for a separate resource for the CreateItem operation is equally valid.
The second aspect involves the URI itself - having determined which document will handle requests, what naming convention should be used for the identifier of that document.
Once again, machines aren't overly concerned. It must adhere to RFC 3986 standards, and using a spelling that aligns well with URI Templates can simplify matters. However, there is still flexibility in this decision.
The general advice? Consider the end users - those viewing browser histories, crafting API documentation, or analyzing access logs to comprehend traffic patterns. Choose a naming convention that is user-friendly and serves the individuals you prioritize.