Repository navigation
r2.1
Pre-release
Pre-release
Release Notes
This release candidate contains the definition and documentation of
- application-endpoint-discovery 0.2.0-rc.1
The API definition(s) are based on
- Commonalities r4.3 (0.8.0)
- Identity and Consent Management r4.2 (0.5.0)
application-endpoint-discovery 0.2.0-rc.1
application-endpoint-discovery 0.2.0-rc.1 is a release-candidate version of this API.
Changes documented below are compared to version 0.1.0.
- API definition with inline documentation:
Breaking changes
- Request bodies containing properties not declared in the API specification, at any nesting level, are now rejected with
400 INVALID_ARGUMENT(Commonalities "Request body strictness" rule) by @maheshc01 in #42 device.ipv4Address.publicPortnow requires a value between 1 and 65535 (previously 0 was accepted), inherited from the CommonalitiesPortschema by @maheshc01 in #42
Added
- Added API-specific
422 APPLICATION_ENDPOINT_DISCOVERY.IDENTIFIER_MISMATCHerror code, returned when bothappIdandapplicationEndpointsIdare provided but theapplicationEndpointsIdis not associated with the application identified byappIdby @urvika-v in #48 - Added API-specific
404 NOT_FOUNDexamples forappIdnot found andapplicationEndpointsIdnot found by @urvika-v in #48 - Added test scenarios for
422 APPLICATION_ENDPOINT_DISCOVERY.IDENTIFIER_MISMATCH, forappIdandapplicationEndpointsIdprovided together, for multiple endpoints ordered by optimality, and for400 INVALID_ARGUMENTon empty request body, non-schema-compliant application identifiers and invalidx-correlatorby @maheshc01 in #54
Changed
- Aligned the API with CAMARA Commonalities r4.3 (0.8.0) and Identity and Consent Management r4.2 (0.5.0) by @maheshc01 in #42
- Common definitions reused via
$refintoCAMARA_common.yaml(openId,x-correlator,Device,DeviceResponse,ErrorInfo,Port, and the generic401and429error responses) - Added the mandatory
info.descriptionsections (authorization and authentication, additional error responses, request body strictness, identifying the device from the access token) - Request bodies with undeclared properties are rejected with
400 INVALID_ARGUMENT(see Breaking changes) device.ipv4Address.publicPortminimum raised from 0 to 1 (see Breaking changes)Devicesemantics follow Commonalities 0.8.0: when several device identifiers are provided, the API provider uses one of them without checking that they identify the same device, and echoes the one used indevicein the response- Added
maxLength,formatandpatternconstraints to string fields includingFqdn,Ipv4Address,Ipv6Address, and description/name fields - Added
maxItems: 50to theapplicationEndpointsresponse array;maxItems: 1toipv4Addressesandipv6Addresses(one address per endpoint)
- Common definitions reused via
applicationEndpointsarray is now documented as ordered by optimality descending: the first entry is the most optimal endpoint by @urvika-v in #48edgeCloudZoneStatusis now a required field inEdgeCloudZoneanddefault: unknownis removed. API providers must always return an explicit status value (active,inactiveorunknown). This is a new obligation on API providers and is not a breaking change for API consumers by @urvika-v in #48- Documented behavior when both
appIdandapplicationEndpointsIdare provided: consistent →200 OKwith both identifiers echoed; mismatched →422 APPLICATION_ENDPOINT_DISCOVERY.IDENTIFIER_MISMATCHby @urvika-v in #48 - Documented absence semantics for optional response fields (
edgeCloudZone,applicationEndpointDescription,edgeCloudRegion,applicationServerProviderName,applicationProfileId) by @urvika-v in #48 devicerequest property description updated to reference the "Identifying the device from the access token" section by @urvika-v in #48- Test definitions aligned with the documented error codes and semantics and with the Commonalities API Testing Guidelines (step phrasing, C01 device error scenarios, success scenarios assert at least one endpoint) by @maheshc01 in #54
Fixed
info.descriptionand examples aligned with the schema: endpoint definition requires at least one offqdn,ipv4Addresses,ipv6Addresses(property names corrected to camelCase);404 IDENTIFIER_NOT_FOUNDis documented for a device identifier that cannot be matched, while token-based device identification errors are422 MISSING_IDENTIFIER/422 UNNECESSARY_IDENTIFIER;400example no longer states that exactly one application identifier must be present by @maheshc01 in #54
Removed
- Removed
INVALID_TOKEN_CONTEXTfrom the403response: the API scope does not allow confirming whether request identifiers match the access token by @urvika-v in #48 - Removed
OUT_OF_RANGEfrom the400response: the API has no range-checked input fields by @urvika-v in #48 - Removed
SERVICE_NOT_APPLICABLEandUNSUPPORTED_IDENTIFIERfrom the422response: not applicable to this API by @urvika-v in #48 - Removed test scenarios for
422 UNSUPPORTED_IDENTIFIER,422 SERVICE_NOT_APPLICABLEand503 UNAVAILABLE, which are no longer documented in the API definition by @maheshc01 in #54
Full Changelog: r1.2...r2.1