REST API Mülakat Soruları ve Yanıtları (2026 Rehberi)

REST API'ler, internet üzerindeki entegrasyonların çoğunu güçlendirir. Back-end, full stack ya da yazılım mühendisliği pozisyonlarına başvururken, muhtemelen REST API tasarımı, HTTP yöntemleri ve kimlik doğrulama desenleri hakkında sorularla karşılaşacaksınız.

Bu rehberde, mülakatçilerin gerçekten sorduğu sorular üzerinden gideceğim. Hedef pozisyonunuza en uygun konulara odaklanabilmeniz için soruları zorluk seviyesine ve role göre düzenledim. Her yanıtta pratik örnekler ve ilgili yerlerde uyarlayabileceğiniz kod parçacıkları var.

Aklınızda tutmanız gereken bir nokta: mülakatçılar, ileri düzey konulardan çok temelleri test eder. Temelleri (HTTP yöntemleri, durum kodları, durum bilgisiz yapı) sağlam kavrarsanız, çoğu REST API mülakatını özgüvenle yönetirsiniz. Gösterişli mimari kalıplar daha sonra gelir.

Temel REST API Mülakat Soruları

Bu sorular temel bilginizi ölçer. Kıdem seviyesinden bağımsız olarak neredeyse her mülakatta karşınıza çıkar.

1. REST nedir ve kısıtları nelerdir?

REST, Temsili Durum Transferi (Representational State Transfer) anlamına gelir. Roy Fielding'in 2000 tarihli doktora tezinde tanımlanan, ağ tabanlı uygulamalar için bir mimari stildir.

REST'in altı kısıtı vardır:

1. İstemci-Sunucu: Kullanıcı arayüzü ile veri depolamanın ayrılması
2. Durum Bilgisiz: Her istek, tamamlanması için gereken tüm bilgileri içerir
3. Önbelleğe Alınabilir: Yanıtlar, önbelleğe alınıp alınamayacağını belirtmelidir
4. Katmanlı Sistem: Bileşenler, bulundukları katmanın ötesini göremez
5. Tekdüze Arayüz: Kaynaklarla etkileşimin standartlaştırılmış yolu
6. Talep Üzerine Kod (opsiyonel): Sunucular, istemcilere çalıştırılabilir kod gönderebilir

2. REST ve SOAP arasındaki fark nedir?

REST bir mimari stildir; SOAP ise bir protokoldür. REST genellikle HTTP üzerinde JSON kullanır ve standart HTTP yöntemlerinden yararlanır. SOAP yalnızca XML kullanır ve zarf ve başlıklarla kendi mesajlaşma formatını tanımlar.

SOAP, resmi sözleşmeler (WSDL) veya mesaj düzeyi güvenlik (WS-Security) gerektiren kurumsal sistemler için hâlâ mantıklıdır.

3. HTTP yöntemleri nelerdir ve her birini ne zaman kullanırsınız?

HTTP yöntemleri, bir kaynak üzerinde gerçekleştirilecek işlemi tanımlar.

4. PUT ve POST arasındaki fark nedir?

POST, URI'yi sunucunun belirlediği yeni bir kaynak oluşturur. PUT, istemcinin belirttiği belirli bir URI'deki kaynağı değiştirir.

POST /users          → Server creates user, returns /users/123
PUT /users/123       → Client specifies URI, replaces entire resourceAltyapı:

Var olmayan bir URI'ye PUT yaparsanız, sunucu onu oluşturabilir. Mevcut bir URI'ye PUT yaparsanız, tüm kaynağı değiştirirsiniz.

5. PUT ve PATCH arasındaki fark nedir?

PUT tüm kaynağı değiştirir. PATCH kısmi değişiklikler uygular.

# PUT replaces everything
PUT /users/123
{"name": "Khalid", "email": "[email protected]", "role": "admin"}

# PATCH updates only specified fields
PATCH /users/123
{"role": "admin"}Altyapı:

6. REST'te "durum bilgisiz" ne anlama gelir?

Durum bilgisiz, her isteğin sunucunun işlemesi için gereken tüm bilgileri içermesi gerektiği anlamına gelir. Sunucu, istekler arasında herhangi bir istemci bağlamı saklamaz.

Bu, sunucu tarafı oturumların olmadığı anlamına gelir. Bir kullanıcı kimliği doğrulanmışsa, istemci her istekte kimlik bilgilerini (genellikle bir belirteç) göndermelidir.

7. Bir API'yi RESTful yapan nedir?

Bir API, HATEOAS (Application State'in Motoru Olarak Hipermedya) dahil tüm REST kısıtlarını sağladığında gerçekten RESTful sayılır. Pratikte, kendine "REST" diyen çoğu API aslında "REST-benzeri" ya da Richardson Olgunluk Modeli Seviye 2'dedir. Dürüst olmak gerekirse, çoğu kullanım senaryosu için bu yeterlidir.

REST API'leri için Richardson Olgunluk Modeli seviyeleri. Görsel: Yazar.

8. Bilmeniz gereken temel HTTP durum kodları nelerdir?

API senaryolarının çoğunu kapsayan en az şu yedi temel durum koduna aşina olmalısınız:

9. Kaynak ile uç nokta arasındaki fark nedir?

Bir kaynak, veri varlığıdır (kullanıcı, sipariş, ürün). Bir uç nokta, o kaynağa erişim sağlayan URL yoludur.

Resource: User
Endpoints: GET /users, GET /users/123, POST /usersAltyapı:

10. URI tasarımı için en iyi uygulamalar nelerdir?

Fiiller değil, isimler kullanın. URI'leri küçük harfle ve birden çok kelimede kısa çizgiyle yazın. Koleksiyonlar için çoğul isimler kullanın.

Good:  /users, /users/123, /order-items
Bad:   /getUsers, /Users, /order_itemsAltyapı:

Derin iç içe yapıları kaçının. /users/123/posts/456/comments/789 yerine /comments/789 veya /comments?post_id=456 düşünün.

11. İdempotentlik nedir ve hangi HTTP yöntemleri idempotenttir?

Bir işlem, birden fazla kez yapılması tek sefer yapılmasıyla aynı sonucu üretiyorsa idempotenttir.

Bir değeri ayarlayan PATCH idempotenttir; bir sayacı artıran PATCH değildir.

12. Güvenli ve idempotent yöntemler arasındaki fark nedir?

Güvenli yöntemler kaynakları değiştirmez (GET, HEAD, OPTIONS). İdempotent yöntemler birden fazla kez çağrılsa da aynı etkiyi yaratır (GET, PUT, DELETE).

Tüm güvenli yöntemler idempotenttir, ancak tüm idempotent yöntemler güvenli değildir. DELETE idempotenttir fakat güvenli değildir çünkü durumu değiştirir.

13. Sorgu parametrelerini ne zaman, yol parametrelerini ne zaman kullanmalısınız?

Yol parametreleri belirli bir kaynağı tanımlar. Sorgu parametreleri koleksiyonları filtreler, sıralar veya sayfalar.

Path:   /users/123              (specific user)
Query:  /users?status=active    (filtered collection)
        /users?sort=name&limit=10Altyapı:

14. İçerik müzakeresi (content negotiation) nedir?

İçerik müzakeresi, istemcilerin bir kaynağın farklı temsillerini talep etmesine olanak tanır. İstemci bir Accept başlığı gönderir ve sunucu uygun formatla yanıt verir.

Accept: application/json    → Server returns JSON
Accept: application/xml     → Server returns XMLAltyapı:

15. OPTIONS yönteminin amacı nedir?

OPTIONS, bir sunucunun belirli bir URL için desteklediği HTTP yöntemlerini döndürür. Tarayıcılar, çapraz kaynak isteklerine izin verilip verilmediğini kontrol etmek için CORS preflight isteklerinde kullanır.

Orta Düzey REST API Mülakat Soruları

Bu sorular, pratik uygulama ve karar alma yeteneğinizi ölçer. Orta düzey pozisyonlarda bekleyin.

16. 401 ile 403 arasındaki fark nedir?

Bu, en sık karıştırılan durum kodu ikilisidir. Kıdemli mühendislerin bile kod incelemelerinde bunları karıştırdığını gördüm.

401 Unauthorized

Kimliği doğrulanmamış demektir. Sunucu kimsiniz bilmiyor. Yanıtınız, kullanıcıyı oturum açmaya yönlendirmelidir.

403 Forbidden

Yetkisiz demektir. Sunucu kimsiniz biliyor ancak izniniz yok. Yeniden kimlik doğrulamak işe yaramaz.

Kimlik doğrulama ve yetkilendirme hata karar akış şeması. Görsel: Yazar.

17. 400 ile 422 arasındaki fark nedir?

Farkı açıklayan örnekler şunlardır:

400 Bad Request

Bozuk sözdizimini belirtir. Sunucu isteği ayrıştıramaz (geçersiz JSON yapısı, eksik zorunlu başlıklar).

422 Unprocessable Entity

Geçerli sözdizimi ancak anlamsal hatalar olduğunu belirtir. JSON geçerlidir ama veriler doğrulamadan geçmez (geçersiz e-posta formatı, çok kısa parola).

# 400: Cannot parse
{"name": "Khalid",}  # Trailing comma breaks JSON

# 422: Valid JSON, invalid data
{"email": "not-an-email"}  # Fails validationAltyapı:

18. 409 Conflict'i ne zaman kullanmalısınız?

İstek, kaynağın mevcut durumu ile çakıştığında 409 kullanın:

• İyimser kilitleme hataları (ETag uyuşmazlığı)
• Benzersizlik ihlalleri (çift kullanıcı adı)
• Geçersiz durum geçişleri (çoktan gönderilmiş bir siparişi iptal etmek)

19. Sayfalama nasıl uygulanır?

İki ana yaklaşım:

Offset tabanlı sayfalama

Basittir ancak büyük veri kümelerinde performans sorunları vardır.

GET /users?limit=20&offset=40Altyapı:

İmleç (cursor) tabanlı sayfalama

Daha iyi ölçeklenir ve veri değiştiğinde "sayfa kaymasını" önler.

GET /users?limit=20&cursor=eyJpZCI6MTIzfQAltyapı:

Stripe, GitHub ve Slack gibi şirketler, büyük veri kümeleri için imleç tabanlı sayfalama kullanır.

20. Yaygın API versiyonlama stratejileri nelerdir?

Üç ana yaklaşım vardır, her birinin farklı ödünleşimleri bulunur:

URI versiyonlama

En yaygın olanıdır. Açık ve hata ayıklaması kolaydır.

GET /v1/users
GET /v2/usersAltyapı:

Başlık ile versiyonlama

URL'ler daha temizdir ancak tarayıcılarda test etmesi zordur.

GET /users
Accept-Version: v2Altyapı:

Sorgu parametresi ile versiyonlama

Eklemek kolaydır ama URL'leri karmaşıklaştırır.

GET /users?version=2Altyapı:

21. ETag nedir ve önbellekleme nasıl çalışır?

ETag, bir kaynak için sürüm tanımlayıcıdır. Sunucu bunu yanıtlarda gönderir; istemci, kaynağın değişip değişmediğini kontrol etmek için sonraki isteklerde geri gönderir.

# First request
GET /users/123
Response: ETag: "abc123"

# Subsequent request
GET /users/123
If-None-Match: "abc123"
Response: 304 Not Modified (if unchanged)Altyapı:

22. REST API'leri için hangi kimlik doğrulama yöntemleri kullanılır?

En yaygın dört yöntem API Keys, Bearer Tokens, OAuth 2.0 ve JWT'dir:

23. JWT nedir ve nasıl çalışır?

JWT (JSON Web Token) üç parçadan oluşur: Header, Payload ve Signature. Python'da JSON ile çalışma hakkında daha fazla bilgi edinin.

Header: {"alg": "RS256", "typ": "JWT"}
Payload: {"sub": "user123", "exp": 1704153600}
Signature: RSASHA256(base64(header) + "." + base64(payload), privateKey)Altyapı:

Sunucu belirteci imzalar; istemciler isteklerle birlikte gönderir. Sunucu, veritabanı sorgusu yapmadan imzayı doğrular.

24. RS256 ile HS256 arasındaki fark nedir?

HS256 (simetrik): Aynı gizli anahtar imzalar ve doğrular. Birden fazla hizmetin belirteç doğrulaması yapması gerektiğinde risklidir.

RS256 (asimetrik): Özel anahtar imzalar, açık anahtar doğrular. Belirteçleri birden çok hizmetin doğruladığı dağıtık sistemler için önerilir.

25. HATEOAS nedir?

HATEOAS (Application State'in Motoru Olarak Hipermedya), yanıtlarda ilgili eylem ve kaynaklara bağlantılar bulunması demektir.

{
  "id": 123,
  "name": "Khalid",
  "links": [
    {"rel": "self", "href": "/users/123"},
    {"rel": "orders", "href": "/users/123/orders"}
  ]
}Altyapı:

Pratikte, çoğu API HATEOAS'ı tam olarak uygulamaz. Kavramı bilin, ancak çoğu işte tam uyum beklemeyin. Büyük teknoloji şirketleri bile nadiren tamamen HATEOAS uyumlu API'ler oluşturur.

26. Hataları tutarlı bir şekilde nasıl ele alırsınız?

Tutarlı hata yanıtları için RFC 7807 Problem Details formatını kullanın:

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation Error",
  "status": 422,
  "detail": "Email format is invalid",
  "instance": "/users"
}Altyapı:

27. Oran sınırlama (rate limiting) nedir ve neden önemlidir?

Oran sınırlama, API'nizi kötüye kullanıma karşı korur ve adil kullanımı sağlar. Yaygın bir yanıt:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0Altyapı:

28. Filtreleme ve sıralamayı nasıl tasarlarsınız?

Açık kurallarla sorgu parametreleri kullanın:

# Filtering
GET /products?category=electronics&price[gte]=100&price[lte]=500

# Sorting (prefix - for descending)
GET /users?sort=-created_at,nameAltyapı:

İleri Düzey REST API Mülakat Soruları

Bu sorular mimari düşünmeyi ölçer. Kıdemli pozisyonlar için bekleyin.

29. OAuth 2.0 ile OAuth 2.1 arasında neler değişti?

OAuth 2.1, güvenlik en iyi uygulamalarını birleştirir:

Temel mesaj: Tüm istemci türleri için PKCE ile Yetkilendirme Kodu akışını kullanın.

30. Ödeme uç noktaları için idempotentliği nasıl uygularsınız?

POST isteklerini yeniden denemelere karşı güvenli kılmak için idempotency key'leri kullanın:

async def handle_payment(request: Request, payment: PaymentCreate):
    idempotency_key = request.headers.get("Idempotency-Key")
    
    # Check if already processed
    cached = await redis.get(f"idem:{idempotency_key}")
    if cached:
        return JSONResponse(json.loads(cached))
    
    # Process payment
    result = await process_payment(payment)
    
    # Cache result (24-hour TTL)
    await redis.setex(f"idem:{idempotency_key}", 86400, json.dumps(result))
    return resultAltyapı:

İstemci bir UUID üretir ve istekle birlikte gönderir. Aynı anahtar tekrar gelirse, önbellekteki yanıtı döndürün.

31. Dağıtık bir oran sınırlayıcıyı nasıl tasarlarsınız?

Dağıtık sistemlerde, trafik örneklerde dengelendiği için bellek içi sayaçları kullanamazsınız. Bu, adayların sıklıkla takıldığı yaygın bir noktadır.

Mimari:

1. Merkezi sayaç depolaması için Redis kullanın
2. Patlamalara tolerans için Token Bucket algoritmasını uygulayın
3. Yarış koşullarını önlemek için atomik işlemler (Lua betikleri) kullanın

# Pseudocode for Token Bucket
tokens = redis.get(user_id) or max_tokens
if tokens > 0:
    redis.decr(user_id)
    process_request()
else:
    return 429Altyapı:

32. gRPC'yi REST yerine ne zaman seçersiniz?

gRPC'yi şunlar için seçin:

• Dahili mikro servis iletişimi (5-10x aktarım iyileşmesi)
• Gerçek zamanlı akış gereksinimleri
• Bant genişliği kısıtlı mobil-arka uç iletişimi
• Sıkı sözleşmeler gerektiren çok dilli ortamlar

REST'i şunlar için seçin:

• Farklı tüketicileri olan herkese açık API'ler
• Web uygulamaları (evrensel tarayıcı desteği)
• Basit CRUD işlemleri
• Protocol Buffers'a aşina olmayan ekipler

33. Uzun süreli işlemleri nasıl ele alırsınız?

Asenkron istek desenini kullanın:

1. İstemci isteği gönderir

2. Sunucu bir durum URL'siyle 202 Accepted döndürür

3. İstemci tamamlanana kadar durum URL'sini yoklar

POST /reports
Response: 202 Accepted
Location: /reports/abc123/status

GET /reports/abc123/status
Response: {"status": "processing", "progress": 45}

GET /reports/abc123/status
Response: {"status": "completed", "result_url": "/reports/abc123"}Altyapı:

34. Saga deseni nedir?

Saga, mikro servisler arasında kilitleme olmadan dağıtık işlemleri yönetir. Her servis yerel bir işlem yürütür ve bir olay yayınlar. Bir adım başarısız olursa, telafi işlemleri önceki adımları geri alır.

Order Created → Payment Processed → Inventory Reserved → Order Confirmed
                     ↓ (failure)
              Release Payment → Cancel OrderAltyapı:

35. Yaygın JWT güvenlik açıkları nelerdir?

Algoritma karışıklığı: Saldırgan RS256'yı HS256'ya çevirir ve açık anahtarla imzalar. Çözüm: algoritmaları her zaman beyaz listeye alın.

# Vulnerable
jwt.decode(token, key)

# Secure
jwt.decode(token, key, algorithms=["RS256"])Altyapı:

"none" algoritması: Saldırgan imzayı tamamen kaldırır. Çözüm: "none" algoritmasını reddedin.

Back-end Geliştirici REST API Soruları

36. N+1 sorgu problemi nedir?

N+1 problemi, N kayıt getirdikten sonra her kaydın ilişkisi için ayrı bir sorgu çalıştırdığınızda ortaya çıkar.

# N+1 Problem: 101 queries for 100 users
users = User.query.all()  # 1 query
for user in users:
    print(user.posts)     # 100 queriesAltyapı:

Çözümler:

Django: Yabancı anahtarlar için select_related(), çok-çok için prefetch_related() kullanın.

# 2 queries instead of 101
users = User.objects.prefetch_related('posts').all()Altyapı:

SQLAlchemy: joinedload() veya selectinload() kullanın.

37. Bağlantı havuzlamasını nasıl yapılandırırsınız?

Bağlantı havuzlama, her istek için yeni bağlantı oluşturmak yerine veritabanı bağlantılarını yeniden kullanır.

# SQLAlchemy
engine = create_engine(
    "postgresql://user:pass@host/db",
    pool_size=5,           # Permanent connections
    max_overflow=10,       # Temporary overflow
    pool_timeout=30,       # Wait timeout
    pool_pre_ping=True     # Validate before use
)Altyapı:

38. Hangi önbellekleme stratejilerini biliyorsunuz?

Farklı erişim kalıpları için optimize edilmiş üç temel önbellekleme stratejisi vardır:

39. Webhook imza doğrulamasını nasıl uygularsınız?

import hmac
import hashlib

def verify_webhook(payload: bytes, signature: str, secret: str) -> bool:
    expected = 'sha256=' + hmac.new(
        secret.encode(),
        payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)Altyapı:

40. API sağlığını gösteren metrikler nelerdir?

API'nizin sağlığını değerlendirmek için şu dört temel metriği izlemelisiniz:

Full Stack Geliştirici REST API Soruları

41. Tarayıcı ne zaman CORS preflight isteği gönderir?

Tarayıcılar şu durumlarda OPTIONS preflight gönderir:

• GET, HEAD, POST dışındaki yöntemler
• Özel başlıklar (Authorization, X-API-Key)
• form-urlencoded, multipart/form-data, text/plain dışındaki Content-Type

42. CORS'u güvenli şekilde nasıl yapılandırırsınız?

// Express.js
app.use(cors({
  origin: ['https://yourdomain.com'],  // Never use * with credentials
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));Altyapı:

Kimlik bilgileriyle birlikte joker (*) asla kullanmayın. null origin'e asla izin vermeyin.

43. İstemci tarafında belirteçleri nerede saklamalısınız?

Belirteç saklama, XSS ve CSRF zafiyetleri arasında güvenlik ödünleşimleri içerir"

En iyi uygulama: Yenileme belirteçlerini HttpOnly çerezlerde SameSite=Strict ile saklayın. Erişim belirteçlerini bellekte tutun.

44. WebSocket yerine SSE'yi ne zaman kullanmalısınız?

Seçim, çift yönlü iletişime ihtiyaç duyup duymadığınıza ve yeniden bağlanmayı nasıl ele almak istediğinize bağlıdır:

Bildirimler, canlı akışlar, hisse senedi verileri için SSE kullanın. Sohbet, çok oyunculu oyunlar, ortak düzenleme için WebSocket kullanın.

45. Dosya yüklemelerini nasıl ele alırsınız?

Büyük dosyalar için ilerleme takibiyle parçalı yüklemeler kullanın:

async function chunkedUpload(file, chunkSize = 5 * 1024 * 1024) {
  const totalChunks = Math.ceil(file.size / chunkSize);
  
  for (let i = 0; i < totalChunks; i++) {
    const chunk = file.slice(i * chunkSize, (i + 1) * chunkSize);
    await uploadChunk(uploadId, i, chunk);
  }
}Altyapı:

Senaryo Bazlı REST API Soruları

46. Bir otel rezervasyon sistemi için REST API tasarlayın

Kaynaklar:

• /hotels - Otelleri listele ve ara

• /hotels/{id}/rooms - Uygun odalar

• /bookings - Rezervasyon oluştur ve yönet

• /guests/{id} - Misafir profilleri

Kilit kararlar:

• Otel araması için imleç tabanlı sayfalama kullanın
• Oda uygunluğu için iyimser kilitleme uygulayın
• Çifte rezervasyon girişimlerinde 409 Conflict döndürün
• Ödeme işlemleri için idempotency key'leri kullanın

47. Yumuşak silmeleri (soft delete) nasıl uygularsınız?

Kayıtları kaldırmak yerine bir deleted_at zaman damgası ekleyin:

@app.delete("/users/{user_id}")
def delete_user(user_id: int):
    user = db.get(user_id)
    user.deleted_at = datetime.utcnow()
    db.commit()
    return Response(status_code=204)

@app.get("/users")
def list_users(include_deleted: bool = False):
    query = User.query
    if not include_deleted:
        query = query.filter(User.deleted_at.is_(None))
    return query.all()Altyapı:

48. Müşterileri bozmadan v1'den v2'ye nasıl geçiş yaparsınız?

Strangler Fig desenini kullanın:

1. v2'yi v1 ile yan yana devreye alın
2. Yeni özellikleri v2'ye yönlendirin
3. Mevcut uç noktaları kademeli olarak taşıyın
4. Sunset başlığıyla kullanım dışı bırakmayı duyurun
5. Geçiş süresi sonrası v1'i kaldırın

49. Karmaşık filtrelemeli bir arama API'sini nasıl tasarlarsınız?

Birden çok filtreli ürün araması için:

GET /products?q=laptop&category=electronics&price[gte]=500&price[lte]=2000&brand=apple,dell&in_stock=true&sort=-rating&limit=20&cursor=abc123Altyapı:

Tasarım kararları:

• Tam metin arama için Elasticsearch kullanın (ilişkisel DB'ler bulanık eşleşmede zorlanır)
• Mevcut filtre seçeneklerini göstermek için yüzeysel (faceted) arama uygulayın
• Her filtre için sonuç sayısını döndürün ki kullanıcılar her filtrenin kaç sonuç ürettiğini bilsin
• Popüler arama kombinasyonlarını önbelleğe alın

50. Mikro servis mimarisinde API versiyonlamayı nasıl ele alırsınız?

Seçenekler:

1. Ağ geçidi (gateway) düzeyinde versiyonlama: API geçidi /v1/* eski servislere, /v2/* yenilerine yönlendirir

2. Servis düzeyinde versiyonlama: Her servis kendi sürüm uzlaşmasını yönetir

3. Tüketici güdümlü sözleşmeler: Uyumluluğu sağlamak için Pact veya benzeri araçlar kullanın

Çoğu ekip için ağ geçidi düzeyinde versiyonlama en temiz ayrımı sağlar.

51. Farklı kullanıcı katmanları için oran sınırlamayı nasıl uygularsınız?

Çözüm, katmana özel sınırları tanımlayıp bunları Redis sayaçlarıyla denetlemeyi içerir:

RATE_LIMITS = {
    "free": {"requests": 100, "window": 3600},
    "pro": {"requests": 1000, "window": 3600},
    "enterprise": {"requests": 10000, "window": 3600}
}

async def rate_limit_middleware(request: Request):
    user = get_current_user(request)
    tier = user.subscription_tier
    limits = RATE_LIMITS[tier]
    
    key = f"rate:{user.id}:{current_hour()}"
    count = await redis.incr(key)
    
    if count == 1:
        await redis.expire(key, limits["window"])
    
    if count > limits["requests"]:
        raise HTTPException(
            status_code=429,
            headers={
                "X-RateLimit-Limit": str(limits["requests"]),
                "X-RateLimit-Remaining": "0",
                "Retry-After": str(seconds_until_reset())
            }
        )Altyapı:

Davranışsal REST API Soruları

52. REST'i teknik olmayan bir kişiye açıklayın

"Bir REST API'yi, restorandaki bir garson gibi düşünün. Siz (müşteri) mutfağa doğrudan gidemezsiniz. Bunun yerine garsona menüden ne istediğinizi söylersiniz ve o da getirir. Menü, neleri sipariş edebileceğinizi listeleyen API dokümantasyonuna benzer. Garson belirli kuralları izler: bir şeyi istersiniz (GET), yeni bir şey sipariş edersiniz (POST) veya bir şeyi geri gönderirsiniz (DELETE). Mutfakta bir şey kalmadıysa, garson size söyler (404 Not Found) ki sonsuza kadar beklemeyesiniz."

Bu benzetme, paydaş toplantılarında şaşırtıcı derecede iyi çalışır.

53. Bir API'yi optimize ettiğiniz bir zamanı anlatın

STAR yöntemini kullanın:

• Durum: "Arama API'mız yoğun trafikte 3 saniyelik yanıt sürelerine sahipti"
• Görev: "Büyük mimari değişiklikler yapmadan gecikmeyi azaltmam gerekiyordu"
• Aksiyon: "Sık sorgular için Redis önbelleği ekledim, imleç tabanlı sayfalamayı uyguladım ve veritabanı indeksleri ekledim"
• Sonuç: "Yanıt süresi 200 ms'ye düştü ve 5 kat daha fazla trafiği karşıladık"

54. API tüketicilerine kırıcı değişiklikleri nasıl iletirsiniz?

1. Erken duyurun: Büyük değişiklikler için en az 6-12 ay önceden bildirin

2. Sunset başlığı kullanın: Sunset: Sat, 31 Dec 2026 23:59:59 GMT

3. Geçiş kılavuzları sağlayın: Tam olarak neyin değiştiğini ve nasıl uyarlanacağını belgeleyin

4. Her iki sürümü de çalıştırın: Geçiş sırasında eski sürümü açık tutun

5. Kullanımı izleyin: Hangi istemcilerin hâlâ eski sürümde olduğunu takip edin

55. API'ler için hangi dokümantasyonları oluşturursunuz?

Gerekli dokümantasyon şunları içerir:

• OpenAPI/Swagger şeması: Makinece okunabilir sözleşme
• Hızlı başlangıç kılavuzu: 5 dakikanın altında ilk API çağrısı
• Kimlik doğrulama kılavuzu: Kimlik bilgilerinin nasıl alınacağı ve kullanılacağı
• Hata referansı: Tüm olası hata kodları ve nasıl ele alınacakları
• Değişiklik günlüğü: Her sürümde nelerin değiştiği
• Oran sınırı dokümantasyonu: Katman başına limitler ve 429'ların nasıl ele alınacağı

56. REST'i ne zaman KULLANMAZSINIZ?

REST her zaman doğru seçim değildir. alternatifleri ne zaman kullanacağınızı bilmek mimari olgunluğu gösterir. Ekiplerin, REST'in sorun çözdüğünden çok daha fazla sorun yarattığı kullanım durumlarına zorlandığını gördüm.

REST API Hızlı Referans

HTTP yöntem özelliklerini, durum kodlarını veya yaygın kalıpları doğrulamanız gerektiğinde bu bölümü hızlı başvuru olarak kullanın; ister mülakat hazırlığında ister gerçek geliştirmede.

HTTP Yöntemleri Karşılaştırması

Bu tablo, her HTTP yönteminin kilit özelliklerini özetler ve kullanıcı durumunuza uygun olanı seçmenize yardımcı olur.

Durum Kodları Referansı

En yaygın kullanılan HTTP durum kodları burada kategoriye göre düzenlenmiştir. Tüm spesifikasyonu ezberlemekten ziyade her birinin ne zaman kullanılacağını anlamaya odaklanın.

2xx Başarı

• 200 OK: Başarılı GET, PUT, PATCH
• 201 Created: Başarılı POST (Location başlığını ekleyin)
• 204 No Content: Başarılı DELETE

4xx İstemci Hataları

• 400 Bad Request: Bozuk sözdizimi
• 401 Unauthorized: Kimlik doğrulama gerekli
• 403 Forbidden: Kimliği doğrulanmış ancak yetkili değil
• 404 Not Found: Kaynak mevcut değil
• 409 Conflict: Durum çakışması
• 422 Unprocessable Entity: Doğrulama hatası
• 429 Too Many Requests: Oran sınırı aşıldı

5xx Sunucu Hataları

• 500 Internal Server Error: Genel sunucu hatası
• 502 Bad Gateway: Yukarı akış sunucu hatası
• 503 Service Unavailable: Geçici olarak aşırı yük

Kaçınılması Gereken Yaygın Hatalar

Deneyimli geliştiriciler bile bu tuzaklara düşer. REST API tasarlarken veya uygularken şu yaygın hatalara dikkat edin:

• URL'lerde fiil kullanmak (ör. /getUsers yerine /users)

• Hata durumları için 200 OK döndürmek; bu, istemci tarafı hata yönetimini bozar

• 401 ile 403'ü karıştırmak (Kimlik Doğrulama vs. Yetkilendirme)

• URL'leri iki seviyeden fazla iç içe yapmak

• Belirteçleri localStorage'da saklamak (XSS açıkları yaratır)

• POST isteklerinde idempotentliği göz ardı etmek

• Eyleme geçirilebilir ayrıntılar içermeyen genel hata mesajları döndürmek

Sonuç

Tanımları ezberlemenin her teknik mülakattan geçmenizi garanti etmeyeceğinin farkındayım. Gerçek şu ki, gerçek dünya mühendisliği sıklıkla az önce bahsettiğimiz "katı" kuralları esnetmeyi gerektirir ve mülakatçılar, RFC spesifikasyonlarını ezbere okumaktan ziyade muhakemenize önem verir. Çok uzmanlaşmış roller için, derin alan bilgisi veya belirli bir çerçevede uzmanlık yine belirleyici olabilir.

Ancak bu REST temellerine hâkim olmak, bu sorularla birebir karşılaşmasanız bile önemlidir. Bu, modern webin nasıl çalıştığını anlamak için bir plan görevi görür. Yeni bir sistem tasarlamanız ya da üretimde bir kesintiyi hata ayıklamanız istendiğinde, (daha önce açıkladığım gibi) 401 ile 403 arasındaki farkı anlamak, sorunları daha hızlı çözmenizi sağlar. Yalnızca çalışan kod yazmak değil, API etkileşimlerinizi standartlaştırmanın da kıdemli bir mühendisin alametifarikası olduğunu net biçimde görürsünüz.

Bu sistemleri derinlemesine inşa etmeye dalmak isterseniz, Python ile API'lere Giriş kursumuza göz atın.