Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Add a way to combine ApiDescription instances

オープン
  • 何か問題がありますか？
#1,069 コメント 0 件 リアクション 4 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@colinmarc がすでに取り組んでいます。

2026年3月23日 から。

  • #1574 @colinmarc による — オープン

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
rust
領域
backend-api-design

調査の方向性

まず ApiDescription 型とその route-handler trie を読み、生成された api_description と stub_api_description のエントリーポイントを比較します。extend と prefixing がエンドポイントの競合、OpenAPI の生成、API traits、issue 869 における複数バージョンのサポートとどのように相互作用するかを検討します。完了条件は、合意された merge 設計と、その実装およびテストが定義されていることです。

索引モデルが issue の本文から書いたものです。

説明

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?

主要言語
Rust
スター
1.2k
フォーク
103
平均マージ
2日 1時間
マージ済み PR（30日）
20

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

oxidecomputer/dropshot のほかの issue

oxidecomputer/dropshot の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。