cbsd-rs: openAPI integration#63
Conversation
|
I will look into it @s0nea |
UweSchwaeke
left a comment
UweSchwaeke
left a comment
There was a problem hiding this comment.
looked into it, only minor tweaks.
| serde = { version = "1", features = ["derive"] } | ||
| serde_json = "1" | ||
| chrono = { version = "0.4", default-features = false, features = ["serde", "clock"] } | ||
| utoipa = { version = "5", features = ["chrono"] } |
There was a problem hiding this comment.
Just a quick heads-up: I believe Joao noted that only dependencies shared across all projects should be listed here.
There was a problem hiding this comment.
While reading through https://dev.to/leapcell/mastering-large-project-organization-in-rust-n11#:~:text=Workspace%20toml%20file
This is because the workspace allows centralizing dependency management. If both cli and server also need thiserror, should we define thiserror = "1.0.61" separately in each of their Cargo.toml files? We could, but this leads to potential issues: if different versions are used across projects, compilation might be slower, and the compiled binaries might contain redundant copies of thiserror.
I'm wondering if we should keep it here because the dependency is used in cbsd-proto as well as cbsd-server.
There was a problem hiding this comment.
@jecluis is it ok if we change it?
up to now:
only put dependencies that are needed by all sub projects in main Cargo.toml.
desired new state:
put dependencies that are shared by at least 2 sub projects in main Cargo.toml.
i think this is a good point.
There was a problem hiding this comment.
Yes, that's indeed the question. If the dependency has to be used by all projects or by some 😄
Add design document, implementation plan, and design review for OpenAPI integration (seq 018). Covers utoipa + Scalar UI serving the spec at /api/docs with compile-time generation. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Tatjana Dehler <tatjana.dehler@clyso.com>
s0nea
force-pushed
the
wip/openapi-integration
branch
from
537ff81 to
a102801
Compare
Derive ToSchema on all REST-facing proto types for OpenAPI spec generation (design 018). WebSocket-only types and WorkerToken are excluded — they are internal protocol types, not part of the documented REST API surface. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Tatjana Dehler <tatjana.dehler@clyso.com>
Derive ToSchema on all server request/response types for OpenAPI spec generation (design 018). Adds explicit schema attributes for serde_json::Value fields so the spec documents them as structured objects rather than opaque strings. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Tatjana Dehler <tatjana.dehler@clyso.com>
Annotate all REST handlers with #[utoipa::path] and convert route modules to OpenApiRouter for automatic spec collection. This enables compile-time OpenAPI spec generation (design 018). Rate-limited auth routes stay on plain Router. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Tatjana Dehler <tatjana.dehler@clyso.com>
Add openapi.rs module with security schemes (bearer PASETO + session cookie), spec assembly, and Scalar UI. Serves browsable API docs at /api/docs and JSON spec at /api/docs/openapi.json for future TypeScript type stub generation (design 018). Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Tatjana Dehler <tatjana.dehler@clyso.com>
s0nea
force-pushed
the
wip/openapi-integration
branch
from
a102801 to
a167cbe
Compare
|
Hey @UweSchwaeke I addressed all your comments and updated the PR. Could you please take one final look? Thank you! 🙂 |
done, sorry for beeing late |
2 participants
The PR integrates the openAPI definition for cbsd-rs.
The browsable API can be found at /api/docs. The openapi.json file at /api/docs/openapi.json.
Co-authored-by: Claude Opus 4.6 (1M context) noreply@anthropic.com
Signed-off-by: Tatjana Dehler tatjana.dehler@clyso.com