Align on Commonalities' subscription-model by using sink and sinkCredentials#335
Conversation
|
@hdamker shell I also update the BadRequest with the error-examples? Generic400:
description: Invalid input
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorInfo"
examples:
InvalidArgument:
value:
status: 400
code: INVALID_ARGUMENT
message: "Schema validation failed at ..."
InvalidCredential:
value:
status: 400
code: INVALID_CREDENTIAL
message: Only Access token is supported
InvalidToken:
value:
status: 400
code: INVALID_TOKEN
message: Only bearer token is supported |
hdamker
left a comment
There was a problem hiding this comment.
sinkCredentials are currently within the Design Guidelines quite restricted. Added here to the descriptions.
d3cab0b to
4f80ca5
Compare
Co-authored-by: Herbert Damker <herbert.damker@telekom.de>
Co-authored-by: Herbert Damker <herbert.damker@telekom.de>
Co-authored-by: Herbert Damker <herbert.damker@telekom.de>
jlurien
left a comment
There was a problem hiding this comment.
You have to correct as well: bearerFormat: "{$request.body#/webhook/notificationAuthToken}" -> bearerFormat: "{$request.body#/sinkCredential.credentialType}"
In QoD Provisioning I have adjusted the previous text to: cc @maxl2287 |
jlurien
left a comment
There was a problem hiding this comment.
I have added also 410 as response to
callbacks:
notifications:
"{$request.body#/sink}":
As in the artifact because it has an explict reference to notifications:
Generic410:
description: Gone
headers:
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
$ref: "#/components/schemas/ErrorInfo"
examples:
GENERIC_410_GONE:
description: Use in notifications flow to allow API Consumer to indicate that its callback is no longer available
value:
status: 410
code: GONE
message: Access to the target resource is no longer available.
Making the linter happy
|
@maxl2287 The additions of Generic410 and Generic422 got mixed up ... may I ask to resolve the conflict? |
@maxl2287 the current Generic400 "BadRequest" is a copy from line 131ff of Commonalities/blob/main/artifacts/CAMARA_common.yaml and fits for the other endpoints. INVALID_CREDENTIAL and INVALID_TOKEN are specific for createSession only - so I suppose you have to introduce and additional |
…e/align-subscription-model # Conflicts: # code/API_definitions/quality-on-demand.yaml
Release notes for r1.2 including: Editorial changes or some entries from r1.1 Added PR #335 which was missed to be mentioned in r1.1
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
Aligns on Commonalities' updated subscription model.
Which issue(s) this PR fixes:
Fixes #332