Analysis of Commonalities 0.6.0-alpha.1 changes

Analysis of Commonalities 0.6.0-alpha.1 changes

(DRAFT)

Changelog

Added

Changed

  • Align 401 wording in Notification Cloud Events Artifact by @PedroDiez in #449

  • Updated types property of Subscription allowing more than one event type per subscription by @eric-murray in #432

Fixed

N/A

Removed

  • Removed AUTHENTICATION_REQUIRED error code by @eric-murray in #429

  • API Design Guidelines document was deprecated by @rartych in #441

 

Analysis

This sections presents of main changes that need to be introduced in API definitions and analysis of impact of changes.

PR

Changes

Required changes in OAS

Breaking change for API Provider implementation

Breaking change for API Client implementation

PR

Changes

Required changes in OAS

Breaking change for API Provider implementation

Breaking change for API Client implementation

Remove AUTHENTICATION_REQUIRED error code in #429

This PR removes the 401 AUTHENTICATION_REQUIRED code from the Commonalities documentation.

Potentially

YES

Potentially

YES

NO

Update `types` property of `Subscription` schema in event-subscription-template.yaml #432

API sub-projects are free to decide to allow more than one event type per subscription.

! To be clarified with Arrays of types (SubscriptionEventType) are still restricted to one within CAMARA-API-Event-Subscription-and-Notification-Guide.md? · Issue #460 · camaraproject/Commonalities

Potentially

YES

(subscription APIs - only if the API wants to use the new possibility)

Potentially

YES

(subscription APIs only)

NO

 

 

 

 

 

Issues and PRs defined in the scope:

Preparation of Meta-relase Fall25 scope · Issue #423 · camaraproject/Commonalities

Expected changes:

PR

Changes

Required changes in OAS

Breaking change for API Provider implementation

Breaking change for API Client implementation

PR

Changes

Required changes in OAS

Breaking change for API Provider implementation

Breaking change for API Client implementation

Remove IDENTIFIER_MISMATCH error and introduce DeviceResp

the API provider must not respond with an error if the identifiers do not match, but instead use only one of the supplied identifiers and indicate which one in the API response.

YES

YES

NO

Not Documented Error Responses info.description

Mandatory text proposed

YES

NO

NO

Text description aligment for duration format fields by PedroDiez · Pull Request #459 · camaraproject/Commonalities

Mandatory text proposed when duration string format is used

Potentially

YES

NO

(change required only if proprietary string format was used for duration attribute)

NO

(change required only if proprietary string format was used for duration attribute)

X-Correlator Format Change

Update x-correlator pattern

YES

NO

NO

Enhancements Subscription/Notification

3.2. subscription-begins event

3.3 subscription-updates event

Added sink pattern and specific 400 - INVALID_SINK error

Potentially

YES

(subscription APIs - only if the API wants to use the new possibility)

Potentially

YES

(subscription APIs only)

NO