-
-
Notifications
You must be signed in to change notification settings - Fork 74
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
feat: support sse
protocol
#252
base: master
Are you sure you want to change the base?
Conversation
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.
Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.
Shouldn't this fall under the HTTP binding instead? |
Would users reading the bindings, know that the SSE-specific information is part of the HTTP bindings? Or is it more for convenience in maintaining them? 🤔 I mean leaning more towards keeping them separate I think 🤔 |
Hey guys, thanks for the feedback. SSE does have a standard content type for http responses, defining the SSE protocol framing, but the message payload defined by the application is contained in that framing, i.e. spanning one or more data fields per SSE event. Therefore message schema types for validation need to be described at a higher level than the SSE http response, as SSE has its own logical channel of application defined messages. |
3f91c86
to
75bc30a
Compare
🤔 This wasn't obvious to me at first glance. Can't we map AsyncAPI channels to these logical channel definitions? Cause I have the feeling that's how it should be but speaking from pure gut feeling. |
Right, the endpoint is identified via URL such as Here we propose to identify the logical channel of messages via the request path, such as |
Then I think http://example.com should be a server definition and |
Are you suggesting that the server definition would use If so, then we would have just the |
Yeah, exactly. That would simplify things IMHO. The server protocol could be |
@fmvilas I've gone with Please let me know if having an |
Yeah now there's nothing in the AsyncAPI document saying that this API MUST use SSE. It only defines that "when using SSE", this message's event type is X. IMHO, there should be something else indicating that an API uses SSE, like server protocol |
This pull request 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 pull request, add a comment with detailed explanation. There can be many reasons why some specific pull request 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 pull request forward. Connect with us through one of many communication channels we established here. Thank you for your patience ❤️ |
Description
sse
message binding objecthttp
protocol in server definitionNote: we are in the process of testing these proposed changes with
zilla
open source project to confirm they are suffcient to supportsse
message validation, etc.See aklivity/zilla#952