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.
