Você também pode usar funções `def` normais (sem `async`) e usar `yield` da mesma forma.

O FastAPI garantirá a execução correta para não bloquear o event loop.

Como, neste caso, a função não é assíncrona, o tipo de retorno adequado seria `Iterable[Item]`:

{* ../../docs_src/server_sent_events/tutorial001_py310.py ln[28:31] hl[29] *}

### Sem tipo de retorno { #no-return-type }

/// tip | Dica

Essa é uma técnica relativamente avançada, e na maioria dos casos você não vai precisar dela, já que você pode levantar exceções (incluindo `HTTPException`) dentro do resto do código da sua aplicação, por exemplo, na *função de operação de rota*.

Mas ela existe para ser utilizada caso você precise. 🤓

///

{* ../../docs_src/dependencies/tutorial008b_an_py310.py hl[18:22,31] *}

        code ->> function: say_hi(name="Camila")
        function ->> code: devolver resultado almacenado
    end
```

En el caso de nuestra dependencia `get_settings()`, la función ni siquiera toma argumentos, por lo que siempre devuelve el mismo valor.

De esa manera, se comporta casi como si fuera solo una variable global. Pero como usa una función de dependencia, entonces podemos sobrescribirla fácilmente para las pruebas.

Atacantes poderiam simplesmente executar um script para enviar requisições à sua API, sem necessidade de interação do navegador, então você provavelmente já está protegendo quaisquer endpoints privilegiados.

Nesse caso, esse ataque/risco não se aplica a você.

Esse risco e ataque é relevante principalmente quando a aplicação roda na rede local e essa é a única proteção presumida.

/// tip | Dica

Se você quer algo rápido para copiar e colar, não use este exemplo, use o último abaixo.

///

Então, quando você cria uma instância dessa classe `Settings` (neste caso, no objeto `settings`), o Pydantic vai ler as variáveis de ambiente sem diferenciar maiúsculas de minúsculas; assim, uma variável em maiúsculas `APP_NAME` ainda será lida para o atributo `app_name`.

* O cliente não tem acesso aquele recurso.
* O item que o cliente está tentando acessar não existe.
* etc.

Nesses casos, você normalmente retornaria um **HTTP status code** próximo ao status code na faixa do status code **400** (do 400 ao 499).

Isso é bastante similar ao caso do HTTP status code 200 (do 200 ao 299). Esses "200" status codes significam que, de algum modo, houve sucesso na requisição.

### Contêineres com Múltiplos Processos e Casos Especiais { #containers-with-multiple-processes-and-special-cases }

Claro, existem **casos especiais** em que você pode querer ter **um contêiner** com vários **processos workers do Uvicorn** dentro.

Nesses casos, você pode usar a opção de linha de comando `--workers` para definir o número de workers que deseja executar:

### Archivos y async { #files-and-async }

En la mayoría de los casos, los objetos tipo archivo no son compatibles con `async` y `await` por defecto.

Por ejemplo, no tienen un `await file.read()`, ni un `async for chunk in file`.

Y en muchos casos leerlos sería una operación bloqueante (que podría bloquear el event loop), porque se leen desde disco o desde la red.

    * `200` é o código de status padrão, o que significa que tudo estava "OK".
    * Outro exemplo seria `201`, "Criado". É comumente usado após a criação de um novo registro no banco de dados.
    * Um caso especial é `204`, "Sem Conteúdo". Essa resposta é usada quando não há conteúdo para retornar ao cliente e, portanto, a resposta não deve ter um corpo.

De esta manera podrás tener las cosas ordenadas y agrupadas correctamente para el código del cliente:

<img src="/img/tutorial/generate-clients/image06.png">

En este caso tienes:

* `ItemsService`
* `UsersService`

### Nombres de los métodos del cliente { #client-method-names }

Ahora mismo los nombres de los métodos generados como `createItemItemsPost` no se ven muy limpios: