Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Add a way to combine ApiDescription instances

Đang mở
  • Có gì không ổn?
#1,069 0 bình luận 4 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

@colinmarc đang làm issue này rồi.

Từ ngày 23/3/2026.

  • #1574 của @colinmarc — đang mở

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
rust
Lĩnh vực
backend-api-design

Hướng nghiên cứu

Bắt đầu bằng cách đọc kiểu ApiDescription và route-handler trie của nó, sau đó so sánh các entry point được tạo api_description và stub_api_description. Hãy xem xét cách extend và prefixing tương tác với các xung đột endpoint, việc tạo OpenAPI, API traits và hỗ trợ nhiều phiên bản trong issue 869; hoàn thành nghĩa là đã xác định được một thiết kế merge thống nhất cùng phần triển khai và các bài kiểm thử của nó.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Currently, Dropshot doesn't provide a first class way to split up an API into "components" or "parts". With function-based servers this isn't a huge issue because you can just write functions of the form:

fn register_component(description: &mut ApiDescription<MyContext>) -> Result<(), ApiDescriptionRegisterError> {
    // ...
}

And then call these register_component functions in a higher-level constructor.

But with API traits, the proc macro generates functions (api_description and stub_api_description) that create ApiDescription instances and register all associated endpoints in one go. So it's not possible to write functions of the form register_component.

How can we address this? Well, one option is to also generate functions of the form register_component. But that leads to some confusion. For example, how would tag_config (https://github.com/oxidecomputer/dropshot/pull/1059) work in this world?

It seems like a better solution would be to provide a way to merge or combine two ApiDescription instances into one. An ApiDescription is a route handler trie with some additional information, and it should certainly be possible to combine two tries into one.

Here's what I'm generally imagining:

impl<C: ServerContext> ApiDescription<C> {
    pub fn extend(&mut self, other: ApiDescription<C>) -> Result<(), ApiDescriptionRegisterError> { }

    /// Merges an `ApiDescription` into `self`, applying a prefix to all endpoints in `other`.
    pub fn extend_with_prefix(&mut self, other: ApiDescription<C>, prefix: &str) -> Result<(), ApiDescriptionRegisterError> { }

    // ... could also provide an extend method with a callback that transforms endpoint
    // paths in `other`, so that e.g. a component can be inserted in the middle
}

This opens up some flexibility:

  • OpenAPI documents can be generated for arbitrary component combinations. For example, experimental endpoints can be separated out into their own trait. This lets us generate two OpenAPI documents, one with experimental endpoints and one without.
  • With API traits, an API can consist of not just one trait but several, and test implementations can choose to implement only part of the API.
  • This solves some of the use cases in RFD 479 without needing macros.

There are some downsides, though:

  • This opens up the possibility that the OpenAPI document and the implementation don't implement the same set of traits.
  • The API trait macro generates two functions, api_description and stub_api_description, with very different bodies. There's currently no way to write code that's generic over the two functions, and I'm not sure there can be. If we can't solve this, then there are two options:
    1. The code to merge ApiDescription instances will have to be written twice.
    2. Dropshot provides some macro-based support for this.
  • I don't think this completely addresses the delegation use case, because even if APIs are broken out into components, test impls may only choose to implement part of a component. We'd still need something like serde's forward_to_deserialize_any.

If we decide to do this, we'll definitely want to think about it in conjunction with multi-version support (https://github.com/oxidecomputer/dropshot/issues/869). For example, should each version be its own trait?

Ngôn ngữ chính
Rust
Star
1.2k
Fork
103
Merge trung bình
1 ngày 15 giờ
Pull request đã merge (30 ngày)
18

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của oxidecomputer/dropshot

Tất cả issue của oxidecomputer/dropshot

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.