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

[FEATURE REQUEST] Relate channel parameter to payload field #199

Closed
jschabowsky opened this issue Apr 16, 2019 · 6 comments · Fixed by #248
Closed

[FEATURE REQUEST] Relate channel parameter to payload field #199

jschabowsky opened this issue Apr 16, 2019 · 6 comments · Fixed by #248
Assignees
Labels

Comments

@jschabowsky
Copy link
Contributor

jschabowsky commented Apr 16, 2019

Is your feature request related to a problem? Please describe.
AsyncAPI 2.0.0/next version supports parameters in channel names which is great. But, there is no context as to where the value comes from. One of the things I see often is that the parameter is populated from the runtime event payload. If we supported noting this context, code generation could do this lifting and make the experience easier for developers.

Can't it be tackled using specification extensions?
The specification needs some sort of a context field that is optional.

Describe the solution you'd like
See below:

{
  "user/{userId}/signup": {
    "parameters": [
      {
        "name": "userId",
        "description": "Id of the user.",
         "context": "payload" <-- add something like this, maybe an enumeration of fields
        "schema": {
          "type": "string"
        }
      }
    ],
    "subscribe": {
      "$ref": "#/components/messages/userSignedUp"
    }
  }
}

Describe alternatives you've considered
N/A

Additional context
N/A

@fmvilas fmvilas changed the title [FEATURE REQUEST] [FEATURE REQUEST] Relate channel parameter to payload field Apr 16, 2019
@fmvilas
Copy link
Member

fmvilas commented Apr 16, 2019

This is a great idea. We can probably use Runtime Expressions as we did with Correlation IDs: https://github.com/asyncapi/asyncapi/blob/master/versions/next/asyncapi.md#correlationIdObject

@fmvilas
Copy link
Member

fmvilas commented Apr 16, 2019

In case you use "context", "schema" is not needed because it will be taken directly from the definition of the payload field.

Also, pointing to a payload field makes this field mandatory in the payload or we should provide a default value.

@prdatur
Copy link

prdatur commented Jun 20, 2019

I think mandatory is the best option, In my opinion there will be much cases where no default value exists the example above shows it good. if we subscribe or publish to a channel where a "userId" is a parameter a default value would be crazy :). But, in my experience there will be definitly cases where a default value makes sense. So why not both?

parameters:
  userId:
    type: integer
    default: 4

If a default value is provided it will be used if nothing was provided, if the default value definition does not exists, the parameter becomes mandatory, maybe but only maybe a definition of optional: true without a default value can make the parameter optional?

@fmvilas
Copy link
Member

fmvilas commented Jul 9, 2019

Note to myself: check out #215 before starting to work on this issue.

@jasonmac01
Copy link

+1 using a runtime expression here would be a great idea. We're having similar discussion on runtime expressions for selecting entire payloads. Applying them to parameter extraction within a Channel key would be great.

@fmvilas fmvilas self-assigned this Aug 2, 2019
@asyncapi-bot
Copy link
Contributor

🎉 This issue has been resolved in version 1.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants