Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Add a way to combine ApiDescription instances

Abierto
  • ¿Algo no está bien?
#1,069 0 comentarios 4 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@colinmarc ya está trabajando en esto.

Desde el 23/3/2026.

  • #1574 de @colinmarc — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
rust
Área
backend-api-design

Línea de trabajo

Comienza leyendo el tipo ApiDescription y su route-handler trie, y después compara los entry points generados api_description y stub_api_description. Considera cómo interactúan extend y prefixing con los conflictos entre endpoints, la generación de OpenAPI, los API traits y la compatibilidad con varias versiones en issue 869; se considera terminado cuando estén definidos un diseño de merge acordado, su implementación y sus pruebas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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?

Lenguaje dominante
Rust
Estrellas
1.2k
Forks
103
Merge medio
2 d 1 h
PR fusionados (30 d)
20

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de oxidecomputer/dropshot

Todos los issues de oxidecomputer/dropshot

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.