You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Commonalities has removed the IDENTIFIER_MISMATCH error for Fall25. Instead, a device identifier should not normally be included in responses. It should only be included to disambiguate the identity of the device when:
the endpoint is being accessed using a 2-legged access token; and
the endpoint allows for a device identifier to be provided in the request; and
the API consumer has included multiple device identifiers
The response then includes the device identifier that was used by the implementation
This PR:
Updates documentation in each OAS
Adds relevant examples both for when device disambiguation is required, and when it is not required
Uses DeviceResponse object for the device-roaming-status API and for events in the device-roaming-status-subscriptions API to limit device identifiers in responses to exactly one when used
Removes the IDENTIFIER_MISMATCH error code option from 422 responses
Note; For subscriptions, the CreateSubscriptionDetail schema is used in both requests and responses, so modifying the responses to use the DeviceResponse would require a general update of the subscription schema in Commonalities. For the moment, the existing schema is left unmodified, which means that multiple device identifiers could be provided in responses, but should not.
I think both GET endpoints should never return a device identifier in the responses, but haven't thought through all possible scenarios, so will raise this as a separate issue.
Changelog input
release-note
- Update documentation in each OAS
- Add relevant examples both for when device disambiguation is required, and when it is not required
- Use `DeviceResponse` object for the device-roaming-status API and for events in the device-roaming-status-subscriptions API to limit device identifiers in responses to exactly one when used
- Remove the IDENTIFIER_MISMATCH error code option from 422 responses
The reason will be displayed to describe this comment to others. Learn more.
@eric-murray your initial comment regarding common CreateSubscriptionDetail, so that DeviceResponse can't be used in the subscription is not valid, right?
@eric-murray your initial comment regarding common CreateSubscriptionDetail, so that DeviceResponse can't be used in the subscription is not valid, right?
I modified the events themselves to use DeviceResponse rather than Device, but the responses to the event management endpoints (POST /subscriptions, GET /subscriptions and GET /subscriptions/{subscriptionId}) still use the Device schema. So multiple device identifiers could be included in the responses to those endpoints, even though a maximum of one should be provided.
Changing it to DeviceResponse would require substantial changes to the event schema, which I'd prefer was done by Commonalities (if at all).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
What this PR does / why we need it:
Commonalities has removed the
IDENTIFIER_MISMATCHerror for Fall25. Instead, a device identifier should not normally be included in responses. It should only be included to disambiguate the identity of the device when:The response then includes the device identifier that was used by the implementation
This PR:
DeviceResponseobject for the device-roaming-status API and for events in the device-roaming-status-subscriptions API to limit device identifiers in responses to exactly one when usedNote; For subscriptions, the
CreateSubscriptionDetailschema is used in both requests and responses, so modifying the responses to use theDeviceResponsewould require a general update of the subscription schema in Commonalities. For the moment, the existing schema is left unmodified, which means that multiple device identifiers could be provided in responses, but should not.Which issue(s) this PR fixes:
Fixes #23
Special notes for reviewers:
I think both GET endpoints should never return a device identifier in the responses, but haven't thought through all possible scenarios, so will raise this as a separate issue.
Changelog input
Additional documentation
None