Reputation: 10878
I have a service "job" which is accessed through an API. Users can POST to an endpoint, and the job will start. After some time the result of the job will be post back to a supplied webhook.
There are two main methods of handling IDs in this scenario:
Server side - On job start, an id is passed back to the creator. The creator than holds onto that id and later when the job completes, they will be passed the output with the id and be able to connect the dots.
Client side - The client submits an id with the job. The server makes sure this id is unique, then passes it back later with job completion.
This is the only article I've found on the subject (https://www.techyourchance.com/client-generated-ids-vs-server-generated-ids/)
I honestly can't make heads or tails of these two. My gut says that client side will be less prone to user error (misplacement of ids). Are there any well documented applications which differ between the two?
Upvotes: 1
Views: 2335
Reputation: 10878
Why not both?
I ended up choosing a route that seems to get the best of both behaviors. Allow users to submit an id, then enforce uniqueness internally. Or, allow them to submit their lack of id, and generate one for them.
Client side IDs set up
The biggest risk here is clients who submit pre-used ids (perhaps used by someone else). Currently, the way I enforce avoidance of this issue is to require all submitted ids to begin with the id of the client (eg. client#123_client-generated-id#4
). This way any collisions are on them, and can be used to avoid creating an item more than once.
Server side IDs setup
Either way, it's probably best to return the id of created item. Once you've done that, you can take it a bit further by allowing clients to explicitly not include an id. When that explicit trigger is seen, you can create the id for them and return it as usual.
POST@user/comments -> {
id: null | "NO_ID" | "VOID" | "Special value specified in the docs"
userId: "client#123"
msg: "k"
} -> {
id: "client#123_server-generated-id#5"
}
By doing both of these at the same time, you should be left with a system that's idempotent for power users (as in, they won't accidentally create the same thing twice), and easy for casual users (they wont have to manage an id system).
Upvotes: 2