Websocket spec proposal #2881
Websocket spec proposal #2881
Conversation
| - Add 2 optional fields on the [Operation Object](https://swagger.io/specification/#operation-object) type: | ||
| - `publish`: [Reference Object](https://swagger.io/specification/#reference-object) | `WebSocket Payload Object` - describes the message(s) the client can publish/push to the server. | ||
| - `subscribe`: [Reference Object](https://swagger.io/specification/#reference-object) | `WebSocket Payload Object` - describes the message(s) the client can receive from the server. |
There was a problem hiding this comment.
If both fields can be optional, how can a tool that reads an OpenAPI document identify a web socket endpoint with certainty? If the OpenAPI document author did not supply either field, the endpoint is unrecognisable from a standard endpoint.
What should happen if those fields are added to an operation other than get? Is that possible?
There was a problem hiding this comment.
-
I'd say if either
publishorsubscribeis present, then it's a socket enabled path. If neither is supplied, it should fall back to be recognized as a regular http path. Are you suggesting something more explicit (extra boolean field maybe)? -
I'd say error. Similar situation, as to what should happen if a
GETrequest has arequestBody.
What do you think?
There was a problem hiding this comment.
OK, that would work. If anyone needs more, they can always create a proposal for it!
|
We appreciate the submission but as discussed in the issue this is out of scope for the OpenAPI specification. |
5 participants
Proposal for Websocket spec, resolves #55