///

{* ../../docs_src/separate_openapi_schemas/tutorial002_py310.py hl[10] *}

### Mismo Esquema para Modelos de Entrada y Salida en la Documentación

Y ahora habrá un único esquema para entrada y salida para el modelo, solo `Item`, y tendrá `description` como **no requerido**:

<div class="screenshot">
<img src="/img/tutorial/separate_openapi_schemas/image05.png">
</div>

Neste caso, você terá que garantir que cada ID de operação seja **único** de alguma outra maneira.

Por exemplo, você poderia garantir que cada *operação de rota* tenha uma tag, e então gerar o ID da operação com base na **tag** e no **nome** da *operação de rota* (o nome da função).

### Função Personalizada para Gerar IDs de Operação Únicos

///

{* ../../docs_src/separate_openapi_schemas/tutorial002_py310.py hl[10] *}

### Mesmo Esquema para Modelos de Entrada e Saída na Documentação

E agora haverá um único esquema para entrada e saída para o modelo, apenas `Item`, e `description` **não será obrigatório**:

<div class="screenshot">
<img src="/img/tutorial/separate-openapi-schemas/image05.png">
</div>

Si no eres un "experto" en OpenAPI, probablemente no necesites esto.

///

Puedes establecer el `operationId` de OpenAPI para ser usado en tu *path operation* con el parámetro `operation_id`.

Tienes que asegurarte de que sea único para cada operación.

{* ../../docs_src/path_operation_advanced_configuration/tutorial001.py hl[6] *}

### Usar el nombre de la *función de path operation* como el operationId

///

Você pode definir o `operationId` do OpenAPI que será utilizado na sua *operação de rota* com o parâmetro `operation_id`.

Você precisa ter certeza que ele é único para cada operação.

{* ../../docs_src/path_operation_advanced_configuration/tutorial001.py hl[6] *}

### Utilizando o nome da *função de operação de rota* como o operationId

# Aplicações Maiores - Múltiplos Arquivos

Se você está construindo uma aplicação ou uma API web, é raro que você possa colocar tudo em um único arquivo.

**FastAPI** oferece uma ferramenta conveniente para estruturar sua aplicação, mantendo toda a flexibilidade.

/// info | Informação

Se você vem do Flask, isso seria o equivalente aos Blueprints do Flask.

///

## Um exemplo de estrutura de arquivos

Mas tenha em mente que, como tudo é manipulado na memória, em uma única lista, ele só funcionará enquanto o processo estiver em execução e só funcionará com um único processo.

  url: https://github.com/frankie567
marier-nico:
  login: marier-nico
  count: 2
  avatarUrl: https://avatars.githubusercontent.com/u/30477068?u=c7df6af853c8f4163d1517814f3e9a0715c82713&v=4
  url: https://github.com/marier-nico
Dustyposa:
  login: Dustyposa
  count: 2

### Exemplo na UI da documentação

Com qualquer um dos métodos acima, os `/docs` vão ficar assim:

<img src="/img/tutorial/body-fields/image01.png">

### `Body` com vários `examples`

Alternativamente ao único `example`, você pode passar `examples` usando um `dict` com **vários examples**, cada um com informações extras que serão adicionadas no **OpenAPI** também.

As chaves do `dict` identificam cada exemplo, e cada valor é outro `dict`.

Os parâmetros da função serão reconhecidos conforme abaixo:

* Se o parâmetro também é declarado na **rota**, será utilizado como um parâmetro de rota.
* Se o parâmetro é de um **tipo único** (como `int`, `float`, `str`, `bool`, etc) será interpretado como um parâmetro de **consulta**.
* Se o parâmetro é declarado como um **modelo Pydantic**, será interpretado como o **corpo** da requisição.

/// note | Observação