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

Unify all referencing mechanisms in v3 #829

Closed
fmvilas opened this issue Sep 1, 2022 · 8 comments
Closed

Unify all referencing mechanisms in v3 #829

fmvilas opened this issue Sep 1, 2022 · 8 comments
Labels
💡 Proposal (RFC 1) RFC Stage 1 (See CONTRIBUTING.md) stale

Comments

@fmvilas
Copy link
Member

fmvilas commented Sep 1, 2022

Spin off from this conversation: #663 (comment).

Summary

We use different referencing mechanisms in the spec:

  • By name in components: SecurityRequirement Object
  • By name in servers: Channel.servers property
  • By using $ref: pretty much everywhere

This issue is to discuss if we should unify all of them and how.

@fmvilas
Copy link
Member Author

fmvilas commented Sep 1, 2022

I'm in favor of using $ref everywhere possible. More details in #663 (comment).

@GreenRover
Copy link
Collaborator

I agree. Having it unique would be a good idea.
$ref looks for me as the best solution as well.

Contra:

  • $ref would allow illegal references
operations:
  sendUserSignedUp:
    action: send
    channel:
      $ref: '#/message/xyz' <--- should be /channel/ not /message/

But there for we have schema validator to point out mistakes like this.

Pro:

  • It is unique we not need to be use to handle multiple ways to solve the same problem
  • It is supported by most IDE. Your have jump marks and mouse over support
  • Be more like brother project OpenAPI

@derberg
Copy link
Member

derberg commented Sep 7, 2022

let's do $ref but consistently everywhere

@jonaslagoni
Copy link
Sponsor Member

I agree let's use $ref everywhere. Side effect this way makes it easier for tooling as well.

$ref would allow illegal references

That would almost always be the case (when using references) but as this is always caught by validators and parsers, I am not sure we can even say it's a con 😄

@fmvilas
Copy link
Member Author

fmvilas commented Oct 13, 2022

/progress 60

PR is in place now: #852.

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

@jonaslagoni
Copy link
Sponsor Member

I cannot seem to find the changes in the parser, @fmvilas are you sure this change is complete?

I have the changes in for the spec #852 and JSON Schema files asyncapi/spec-json-schemas#316.

@fmvilas
Copy link
Member Author

fmvilas commented Apr 4, 2023

Yes, it's missing. I created an issue here: asyncapi/parser-js#746. Thanks for the pointer!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💡 Proposal (RFC 1) RFC Stage 1 (See CONTRIBUTING.md) stale
Projects
None yet
Development

No branches or pull requests

4 participants