REST API URI hell
Why are there so many URIs coming back from the REST API? Each result has ClickUri, PrintableUri, Uri, clickUri (lowercase), printableUri (lowercase), uri, raw.clickableuri, raw.printableuri, raw.sysclickableuri, raw.sysuri, and raw.uri. Lowercase clickUri seems to be the true URI based on CoveoJsSearch.js source and ResolveResultClickableUriProcessor, but can I get some clarification on what the rest of them are and why there are so many? Thanks!
Quite a few things (but I admit this is overwhelming):
- On some systems, the URI that uniquely identifies an item is different than the one that can be used to "open" it. For example, in Outlook 365 you cannot open an attachment directly (I think), so the
clickUrifor those is the one that opens the email containing the attachment.
- Then, on some systems the "real" URI is extremely ugly. For example, on an exchange server it's a huge GUID - not very helpful for the end user. For those we generate a human-friendly URI that should only be used for display purposes (
- The fields with the leading uppercase are an artefact from the past, and they are gone in an upcoming version of the API. But we can't start using this version in JS UI without introducing a breaking change (because some implementations are referencing them), so we're waiting for a major version update of the framework to do so.
- In the same fashion, the field names with the
sysprefix are gone in the new version of our Cloud platform, but the V2 version of the REST API still emulates them to allow a seamless transition of older deployments. Again, when the JS UI switches to the new "V3" version (not available yet) those will be gone too.
- Then finally, the fact that some important fields are repeated at the top level and under
rawis something we'll probably drop too in the V3 API.
So, the plan is to have only the required
printableUri in the end.