Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Add a way to combine ApiDescription instances

Aperta
  • Qualcosa non va?
#1,069 0 commenti 4 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@colinmarc ci sta già lavorando.

Dal 23/3/2026.

  • #1574 di @colinmarc — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
rust
Ambito
backend-api-design

Direzione di ricerca

Inizia leggendo il tipo ApiDescription e il relativo route-handler trie, quindi confronta gli entry point generati api_description e stub_api_description. Considera come extend e prefixing interagiscono con i conflitti tra endpoint, la generazione OpenAPI, gli API traits e il supporto per più versioni in issue 869; il lavoro è completo quando sono definiti un design di merge condiviso, la relativa implementazione e i test.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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?

Lingua principale
Rust
Stelle
1.2k
Fork
103
Merge medio
2g 1h
PR unite (30g)
20

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di oxidecomputer/dropshot

Tutte le issue di oxidecomputer/dropshot

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.