İşte o geçmişin bir kısmı.

## Alternatifler { #alternatives }

Bir süredir karmaşık gereksinimlere sahip API'lar oluşturuyor (Makine Öğrenimi, dağıtık sistemler, asenkron işler, NoSQL veritabanları vb.) ve farklı geliştirici ekiplerini yönetiyorum.

Bu süreçte birçok alternatifi araştırmak, test etmek ve kullanmak zorunda kaldım.

Uygulamanıza giriş yapan kullanıcılar yok da robotlar, botlar veya yalnızca bir access token'a sahip başka sistemler mi var? Yine, her şey aynı şekilde çalışır.

Uygulamanız için neye ihtiyacınız varsa o türden bir model, class ve veritabanı kullanın. **FastAPI**, dependency injection sistemiyle bunları destekler.

## Kod boyutu { #code-size }

Frontend ekibi tarafından kullanılabilir (bu ekip siz de olabilirsiniz).

Üçüncü taraf uygulamalar ve sistemler tarafından kullanılabilir.

Ve aynı uygulamayı debug etmek, kontrol etmek ve test etmek için sizin tarafınızdan da kullanılabilir.

## `password` Flow { #the-password-flow }

MySQL veya PostgreSQL gibi ilişkisel veritabanlarıyla nispeten sıkı bağlıdır, bu nedenle Couchbase, MongoDB, Cassandra vb. gibi bir NoSQL veritabanını ana depolama motoru olarak kullanmak pek kolay değildir.

Bunları kullanarak, etkileşimli dokümantasyon sistemleri de dahil olmak üzere tüm bu standart tabanlı araçlardan faydalanabilirsiniz.

OpenAPI şu security scheme’lerini tanımlar:

* `apiKey`: uygulamaya özel bir anahtar; şuradan gelebilir:
    * Bir query parameter.
    * Bir header.
    * Bir cookie.
* `http`: standart HTTP authentication sistemleri, örneğin:

* tüm ilişkisel veritabanları
* NoSQL veritabanları
* harici paketler
* harici API'ler
* authentication ve authorization sistemleri
* API kullanım izleme (monitoring) sistemleri
* response verisi injection sistemleri
* vb.

## Basit ve Güçlü { #simple-and-powerful }

Hiyerarşik dependency injection sistemi tanımlamak ve kullanmak çok basit olsa da, hâlâ oldukça güçlüdür.

**Kubernetes**, Docker Swarm Mode, Nomad veya benzeri, birden çok makinede dağıtık container'ları yöneten karmaşık bir sistemle yönetiyorsanız, replication'ı her container içinde bir **process manager** (ör. worker'lı Uvicorn) kullanarak yönetmek yerine, muhtemelen **küme seviyesinde (cluster level)** ele almak istersiniz.

Kubernetes gibi dağıtık container yönetim sistemleri, gelen request'ler için **load balancing** desteği sunarken aynı zamanda **container replication**'ını yönetmek için...

Response döndürüldükten *sonra* çalıştırılacak arka plan görevleri tanımlayabilirsiniz.

Bu, request’ten sonra yapılması gereken; ancak client’ın response’u almadan önce tamamlanmasını beklemesine gerek olmayan işlemler için kullanışlıdır.

Örneğin:

* Bir işlem gerçekleştirdikten sonra gönderilen email bildirimleri:

* Veri doğrulama.
* Otomatik annotation ve dokümantasyon.

## Diğer veri tipleri { #other-data-types }

Kullanabileceğiniz ek veri tiplerinden bazıları şunlardır:

* `UUID`:
    * Birçok veritabanı ve sistemde ID olarak yaygın kullanılan, standart bir "Universally Unique Identifier".
    * request'lerde ve response'larda `str` olarak temsil edilir.
* `datetime.datetime`:
    * Python `datetime.datetime`.

Veritabanınız çalınırsa, hırsız kullanıcılarınızın düz metin password’lerine değil, sadece hash’lere sahip olur.

Dolayısıyla hırsız, aynı password’leri başka bir sistemde denemeye çalışamaz (birçok kullanıcı her yerde aynı password’ü kullandığı için bu tehlikeli olurdu).

{* ../../docs_src/security/tutorial003_an_py310.py hl[82:85] *}

#### `**user_dict` Hakkında { #about-user-dict }