* `GET` ve `PUT` request'leri için `item_id`'nin type'ının `int` olduğunu doğrular.
    * Değilse, client faydalı ve anlaşılır bir hata görür.
* `GET` request'leri için `q` adlı opsiyonel bir query parameter olup olmadığını kontrol eder (`http://127.0.0.1:8000/items/foo?q=somequery` örneğindeki gibi).
    * `q` parametresi `= None` ile tanımlandığı için opsiyoneldir.
    * `None` olmasaydı zorunlu olurdu (tıpkı `PUT` örneğindeki body gibi).

`SecurityScopes`, dependant'ların tanımladığı tüm scope'ları barındırdığı için, gereken scope'ların token'da olup olmadığını merkezi bir dependency fonksiyonunda doğrulayıp, farklı *path operation*'larda farklı scope gereksinimleri tanımlayabilirsiniz.

Bu kontroller her *path operation* için bağımsız yapılır.

## Deneyin { #check-it }

API dokümanlarını açarsanız, authenticate olup hangi scope'ları authorize etmek istediğinizi seçebilirsiniz.

Virtual environment'i aktive etmek birkaç şeyi daha değiştirir; ancak yaptığı en önemli işlerden biri budur.

## Virtual Environment'i Kontrol Etmek { #checking-a-virtual-environment }

Bir virtual environment'in aktif olup olmadığını örneğin şununla kontrol ettiğinizde:

//// tab | Linux, macOS, Windows Bash

<div class="termy">

```console
$ which python

/home/user/code/awesome-project/.venv/bin/python
```

* Dokümantasyonu kendi dilinize [çevirmeye yardımcı olmak](contributing.md#translations).
    * Başkalarının yaptığı çevirileri gözden geçirmeye de yardımcı olabilirsiniz.
* Yeni dokümantasyon bölümleri önermek.
* Mevcut bir issue/bug'ı düzeltmek.
    * Test eklediğinizden emin olun.
* Yeni bir feature eklemek.
    * Test eklediğinizden emin olun.

* Bu dokümanın hedeflediğiniz dile sıfırdan yeni bir çevirisini yapın (örneğin `translate.py` içindeki `translate-page` komutu). Bu, çeviriyi `docs/{language code}/docs/_llm-test.md` altında oluşturur.
* Çeviride her şeyin yolunda olup olmadığını kontrol edin.
* Gerekirse dile özel prompt'u, genel prompt'u veya İngilizce dokümanı iyileştirin.
* Ardından çeviride kalan sorunları elle düzeltin; böylece iyi bir çeviri elde edin.

"Bunun" asenkron" denmesinin sebebi, bilgisayarın / programın yavaş görevle "senkronize" olmak, görev tam bittiği anda orada olup görev sonucunu almak ve işe devam etmek için hiçbir şey yapmadan beklemek zorunda olmamasıdır.

Bir container, **ana process** (komut/program) çalıştığı sürece çalışır.

Container'larda normalde **tek bir process** olur. Ancak ana process içinden subprocess'ler başlatmak da mümkündür; böylece aynı container içinde **birden fazla process** olur.

Ama **en az bir çalışan process olmadan** çalışan bir container olamaz. Ana process durursa container da durur.

/// tip | İpucu

Tek bir komut için birden fazla env var ayarlamak istiyorsanız aralarına boşluk koyun ve hepsini komuttan önce yazın.

///

Böylece `admin_email` ayarı `"******@****.***"` olur.

`app_name` `"ChimichangApp"` olur.

`items_per_user` ise default değeri olan `50` olarak kalır.

## Ayarları başka bir module'de tutma { #settings-in-another-module }

Bu senaryoda **bir server daha** eklemek ve bazı process'leri orada çalıştırmak daha iyi olur; böylece hepsinin **yeterli RAM'i ve CPU zamanı** olur.

Ayrıca, herhangi bir sebeple API'nizde bir kullanım **spike**'ı olma ihtimali de vardır. Belki viral olur, belki başka servisler veya bot'lar kullanmaya başlar. Bu durumlarda güvende olmak için ekstra kaynak isteyebilirsiniz.

Aynı şey, farklı tipler arasında bir <dfn title="Birden fazla tip arasındaki bir birleşim, 'bu tiplerden herhangi biri' anlamına gelir.">birleşim</dfn> kullandığınızda ve bu tiplerden biri veya birkaçı geçerli bir Pydantic tipi değilse de olur; örneğin şu kullanım patlar 💥:

{* ../../docs_src/response_model/tutorial003_04_py310.py hl[8] *}