You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support for generating documentation for WebSocket APIs.
Use Case
For parity with Type Safe API.
Proposed Solution
While we do have an OpenAPI spec, using the existing documentation generation will produce API docs which look too much like a REST API, for example will include HTTP methods and paths.
Either by modifying or wrapping existing generators, add support for generating documentation which shows each operation and it's input types. It would also be useful to include that the data sent on the websocket needs to be of the format { "route": "<Operation>", "payload": ... }.
Given that redoc produces the best documentation, it's worth investigating whether that can be customised at all.
It may be wise to add a new enum, WebSocketDocumentationFormat instead of reusing DocumentationFormat as we do currently, so as not to tie them together. This wouldn't be considered a breaking change as we throw an error at projen synth time if the user has provided any documentation formats.
Describe the feature
Support for generating documentation for WebSocket APIs.
Use Case
For parity with Type Safe API.
Proposed Solution
While we do have an OpenAPI spec, using the existing documentation generation will produce API docs which look too much like a REST API, for example will include HTTP methods and paths.
Either by modifying or wrapping existing generators, add support for generating documentation which shows each operation and it's input types. It would also be useful to include that the data sent on the websocket needs to be of the format
{ "route": "<Operation>", "payload": ... }
.Given that redoc produces the best documentation, it's worth investigating whether that can be customised at all.
It may be wise to add a new enum,
WebSocketDocumentationFormat
instead of reusingDocumentationFormat
as we do currently, so as not to tie them together. This wouldn't be considered a breaking change as we throw an error at projen synth time if the user has provided any documentation formats.Other Information
Remove the following once implemented:
aws-pdk/packages/type-safe-api/src/project/type-safe-websocket-api-project.ts
Lines 287 to 292 in a0dda50
Acknowledgements
PDK version used
0.23.26
What languages will this feature affect?
No response
Environment details (OS name and version, etc.)
OSX
The text was updated successfully, but these errors were encountered: