Is Unique ID for the resource is necessary a single string-CodePudding

Most of the online tutorials has a end point the looked like this one

/users/{id}
- get
- post

I am currently on a platform where a 3rd party plugins can be integrated/installed and we are not sure, which third party plugins are installed by the customer. In order to get around this problem, we are thinking of converting the above mentioned example to some thing like this

/users/{vendorID}/{pluginID}/{artifactID}
- get
- post

A vendor can have multiple products/plugins and each plugin is made of multiple artifacts. So we assume {vendorID}/{pluginID}/{artifactID} is a unique resource. But this has a side effect of having two extra path parameters. Not sure if its the right ways.

Looking for some insights. Thank you.

CodePudding user response：

Endpoint path can include any number of path parameters. Multiple path parameters are very common when expressing the hierarchy of resources and subresources in an API. For example, GitHub's "Get a branch" endpoint is /repos/{owner}/{repo}/branches/{branch}.

CodePudding user response：

It is perfectly fine, though you can define a function which merges the 3 strings into a single one.

The final addition to our constraint set for REST comes from the code-on-demand style of Section 3.5.3 (Figure 5-8). REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility. However, it also reduces visibility, and thus is only an optional constraint within REST.

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Though if I would be a client developer I would not allow this from security perspective, but it is just as easy to do something like:

userID = base64Encode(JSON.stringify({vendorID, pluginID, artifactID}))

and write into your documentation that userIDs are generated this way or if you distribute userID, then just give the generated one to your users. It can be even not decryptable if you use SHA1 instead of BASE64. So it is not a big deal to generate a unique ID if you have multiple IDs which are unique together. What can be a problem with the upper approach that the JSON object might be unordered, so maybe a JSON array is a better solution or something that certainly keeps order, but not a simple template string like "{vendorID}-{pluginID}-{artifactID}", because that is injectable unlike a serialization method.