Skip to content
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

Merged
merged 10 commits into from
Jun 3, 2024

Conversation

PedroDiez
Copy link
Collaborator

@PedroDiez PedroDiez commented May 2, 2024

What type of PR is this?

  • correction

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:

  1. To be merged after guideline_for_datacontenttype_cloudevent_concept_as_enum #193
  2. Should we take advantage of this PR and align error exceptions for POST /notifications? To align with Create subscription-notification-template.yaml #189. Commented within PR
  3. Removed Exception 415
  4. Refactor bearer format to bearerFormat: "{$request.body#/sinkCredential.credentialType}"

Changelog input

 release-note

Additional documentation

N/A

@PedroDiez PedroDiez added the correction correction in documentation label May 2, 2024
@PedroDiez PedroDiez self-assigned this May 2, 2024
@PedroDiez PedroDiez requested a review from bigludo7 May 2, 2024 19:29
@PedroDiez
Copy link
Collaborator Author

cc @jlurien

artifacts/CAMARA_common.yaml Outdated Show resolved Hide resolved
X-Correlator:
$ref: "#/components/headers/X-Correlator"
x-correlator:
$ref: "#/components/headers/x-correlator"
content:
application/json:
schema:
Copy link
Collaborator Author

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 clear
  • 415, 429 think makes sense to have in PR#189 as well
  • 410 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

Copy link
Collaborator

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.

Copy link
Collaborator Author

@PedroDiez PedroDiez May 3, 2024

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

Copy link
Collaborator Author

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)

Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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?

Copy link
Collaborator

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

PedroDiez and others added 5 commits May 17, 2024 16:38
Co-authored-by: Shilpa Padgaonkar <77152136+shilpa-padgaonkar@users.noreply.github.com>
1-space indentation for compliance with current style
@PedroDiez
Copy link
Collaborator Author

PedroDiez commented May 29, 2024

ready for review
cc @shilpa-padgaonkar @rartych @patrice-conil @bigludo7

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.

Copy link
Collaborator

@shilpa-padgaonkar shilpa-padgaonkar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/LGTM

@shilpa-padgaonkar
Copy link
Collaborator

@patrice-conil or @bigludo7 : Could you kindly review and approve the PR if you find no issues so that we can proceed to merge?

Copy link
Collaborator

@patrice-conil patrice-conil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@PedroDiez
Copy link
Collaborator Author

If no other comments I will be merging on Monday next week

Copy link
Collaborator

@bigludo7 bigludo7 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/LGTM

@PedroDiez PedroDiez merged commit e873182 into main Jun 3, 2024
@rartych rartych deleted the x-correlator_guideline_format_convention branch October 9, 2024 11:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
correction correction in documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

X-Correlator or x-correlator
5 participants