Prefixing Internally Generated IDs with "sps" (i.e. spsOrgId) #5
-
From @acchristensen: So, my hypothesis. SPS will have its own identifiers for many different object types (Orgs, Items, Locations, Documents, etc).
So, putting that all together, I think it makes a lot of sense for us to always call out that a given field is provided by SPS and to aid in making it relatable to SPS. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 5 replies
-
I’ve been thinking through this one a lot lately for the Item API, and I have several concerns with this approach. Prefixing ids is easy enough for an org that is pretty well defined and unique across the entire SPS ecosystem. BUT there are a LOT of internal SPS ids. Just doing it for a domain (Item, Org, Location, Document, etc) may make sense. BUT each table in a database has an internal identifier. And from this proposal each table id returned would require a prefix. Our Attribute Registry schema only contains metadata about how items are described (not even item data itself) would have 25 different id prefixes we would need to account for. Many of these (valid, value, group, datatype, comment, etc) would likely have collisions with other prefixes other teams would create. I am worried we are setting ourselves up to confuse the user more by using this method and likely a headache for ourselves trying to assure ids are unique and the prefix is intelligible. I’m also not quite following where the concern is coming from regarding having an id but not knowing what it is. I can’t think of a time I had an id and not known what it was in the context for the API (usually I have the object with the id assigned via its parameter or have a variable containing them with a name describing what it is). Is this an issue particular to a certain area within SPS (XREF perhaps)? Wondering if we are solving a particular domains problem and it is leaking out to all other domains. |
Beta Was this translation helpful? Give feedback.
-
The concern around identifying objects returned from the API outside the context of the API can come up in different ways. But it's usually going to be troubleshooting. Viewing logs would be one scenario. Or copy/pasting the API response to an email (to send to our support, to share within a company, etc). Or even in an ETL scenario where a customer has dumped the output of SPS API calls to be post-processed by some other systems. |
Beta Was this translation helpful? Give feedback.
-
The work done around URN-like references should provide and answer the need here: https://github.com/SPSCommerce/sps-api-standards/releases/tag/v1.3.0 |
Beta Was this translation helpful? Give feedback.
The work done around URN-like references should provide and answer the need here: https://github.com/SPSCommerce/sps-api-standards/releases/tag/v1.3.0