-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x-correlator_guideline_format_convention #194
Conversation
cc @jlurien |
X-Correlator: | ||
$ref: "#/components/headers/X-Correlator" | ||
x-correlator: | ||
$ref: "#/components/headers/x-correlator" | ||
content: | ||
application/json: | ||
schema: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding Exceptions alignment with PR#189:
400
,401
,403
,500
,503
are clear415
,429
think makes sense to have in PR#189 as well410
not sure about UC for 410. In case we keep it, we should align in PR#189 as well
cc @shilpa-padgaonkar, @patrice-conil, @bigludo7, @rartych, @jlurien
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok for me to add 415 & 429 in PR#189 event if I'm bit dubious about the UC. I will do.
For 410 I'm more in favor to not add it but will follow your guidance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding:
415 - would be the case when API Consumer (Server Side in this flow) does not support "application/json" -> This in principle should never happen because is a guideline of CloudEvent CAMARA proifle
429 - would be the case when API Consumer (Server Side in this flow) receiving many requests over its threshold (could happen)
@patrice-conil Do you have context about why 410, 415, 429 were included in the initial proposal? 339a8e2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
410 - The unique case I think it may apply is the case of that callback no longer available. I mean the Server side decided to switch-off that endpoint. This would be differnet to a 503, because in 503 endpoint exists but is not available temporarily (regular exception for maintenance tasks)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So following your explanation @PedroDiez I understand that we should have 429 & 410 and drop 415.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @PedroDiez,
My understanding:
410 was introduced to handle cases where the callback URL is no longer available.
415 is what the server side should respond if Content-type or Accept are not "application/json" (should never happen) .
429 could be used to handle congestion on the callback endpoint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @patrice-conil, thanks for the clarification! I think we need to align with #189 (POST callback) cc @bigludo7
My view:
-
Keep 410 for the case the endpoint is no longer available (Not 503 case because that one is temporal). Benefit is to have an indication for Telco Operation teams to enable operations procedure to the Subscriber to say "Please be aware there is a flow no longer working, you will need to generate a new subscription with a new callback or in the case of implicit flow to indicate new callback"
-
Would take out 415 - Should never happen because developers MUST adopt CAMARA cloudevent profile (if you think/prefer to have for safety/operation reasons, i.e. to advise an App developer that need to support application/json as a warning to adapt its side to be able to interoperate it is fine)
-
Keep 429
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@PedroDiez If we agree that 415 is out, rest of your PR LGTM & I can provide an approval once this change is done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Co-authored-by: Shilpa Padgaonkar <77152136+shilpa-padgaonkar@users.noreply.github.com>
1-space indentation for compliance with current style
…into x-correlator_guideline_format_convention
…thub.com/camaraproject/Commonalities into x-correlator_guideline_format_convention
ready for review I have updated bearer format to: "{$request.body#/sinkCredential.credentialType}" As https://swagger.io/docs/specification/authentication/bearer-authentication/ indicates, is an optional property and a hint for the client. ( # optional, arbitrary value for documentation purposes), so semantically speaking accordingly to CloudEvents model is the concept of credentialType and we are restricting to be only ACCESSTOKEN (to me makes more sense but to have aligment/consensus on that) If you think it is better to indicate: "{$request.body#/sinkCredential.accessToken}" just because we only allow ACCESSTOKEN so far and the format is "accessToken" (i.e. a string) it is also fine to me. Just to be transparent about this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/LGTM
@patrice-conil or @bigludo7 : Could you kindly review and approve the PR if you find no issues so that we can proceed to merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
If no other comments I will be merging on Monday next week |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/LGTM
What type of PR is this?
What this PR does / why we need it:
This PR covers the
x-correlator
naming guideline adoption.Also given format to CAMARA_common.yaml (2-space indentation)
Documentation impacted (some doubts commented within PR):
Which issue(s) this PR fixes:
Fixes #191
Special notes for reviewers:
Some notes:
Changelog input
Additional documentation
N/A