REST API Temel Rehberi: Nedir ve Nasıl Çalışır

Noves Digital olarak, 150'den fazla projede REST API'lerin merkezinde olduğu sistemler inşa ettik. Bu rehber, modern yazılım ekiplerinde API geliştirme süreçlerini derinlemesine ele alıyor ve teknik kararların arkasındaki mantığı açıklıyor. İster cross-platform mobil uygulama backend'i, ister ölçeklenebilir e-ticaret altyapısı tasarlıyor olun, bu yazı size pratik ve uygulanabilir bilgiler sunacak.

REST (Representational State Transfer), Roy Fielding'in 2000 yılında doktora tezinde tanımladığı bir mimari stildir. Temel prensibi basittir: istemci ve sunucu arasındaki iletişim, kaynakların temsilleri üzerinden durumsuz (stateless) HTTP çağrılarıyla gerçekleşir. Bu durumsuzluk, sunucunun istemci hakkında hiçbir oturum bilgisi saklamaması anlamına gelir; her istek kendi kimlik doğrulama ve bağlam bilgilerini taşımalıdır.

Modern SaaS ürünlerinde ve agile geliştirme süreçlerinde REST, evrensel bir dil haline gelmiştir. JSON formatındaki veri alışverişi, hem insanlar hem de makineler tarafından kolayca okunabilir. Bir API'nin RESTful olması için mutlak kurallar yoktur; Fielding'in tanımladığı altı kısıtlama (istemci-sunucu ayrımı, durumsuzluk, önbelleklenebilirlik, katmanlı sistem, tek tip arayüz ve isteğe bağlı kod aktarımı) yol gösterir. Pratikte ise tutarlı URI yapısı, doğru HTTP metodları ve anlamlı durum kodları kullanmak yeterlidir.

2. Temel Bileşenler: HTTP Metodları, Kaynaklar ve URI Tasarımı

REST mimarisinin üç temel direği vardır: HTTP metodları (GET, POST, PUT, DELETE), kaynaklar (users, orders, products) ve bu kaynaklara erişim yolları olan URI'ler. Bu üçlü, API'nizin "sözleşmesini" oluşturur. İyi tasarlanmış bir API, geliştiricinin tahmin edebileceği bir yapıya sahiptir; /users/123/orders gibi bir endpoint, kullanıcının siparişlerini getireceğini sezdirir.

Kaynak odaklı düşünmek, eylem odaklı düşünmekten farklıdır. /getUser?id=123 yerine /users/123 kullanmak, REST felsefesinin özüdür. URI'ler isim olmalı, fiil olmamalıdır. HTTP metodu zaten eylemi belirtir: GET okur, POST oluşturur, PUT günceller, DELETE siler. Bu ayrım, API'nin öngörülebilirliğini ve test edilebilirliğini artırır.

3. HTTP Metodları Nedir ve Örnekleri

HTTP protokolü, REST API'lerde CRUD operasyonlarını gerçekleştirmek için standart metodlar sunar. GET, sunucudan veri almak için kullanılır ve idempotent'tir (aynı istek tekrarlanırsa aynı sonucu verir). POST yeni kaynak oluşturur ve non-idempotent'tir. PUT, mevcut kaynağı tamamen günceller; PATCH ise kısmi güncelleme yapar. DELETE kaynağı kaldırır.

İki önemli metod daha vardır: HEAD (GET'in body'siz versiyonu, cache kontrolü için) ve OPTIONS (CORS preflight için). Safe metodlar (GET, HEAD, OPTIONS) sunucu durumunu değiştirmez. Idempotent metodlar (GET, PUT, DELETE) ağ hatalarında güvenle yeniden denenebilir. Bu özellik, performans optimizasyonu ve hata kurtarma stratejileri için kritiktir.

GET    /api/v1/users/42          # Kullanıcı detayını getir
POST   /api/v1/users             # Yeni kullanıcı oluştur
PUT    /api/v1/users/42          # Kullanıcıyı tamamen güncelle
PATCH  /api/v1/users/42          # Kullanıcıyı kısmen güncelle
DELETE /api/v1/users/42          # Kullanıcıyı sil

4. Kaynak Modelleme Nasıl Yapılır

Kaynak modelleme, domain'inizi API endpoint'lerine dönüştürme sanatıdır. İlk adım, iş domaininizdeki varlıkları (entities) tanımlamaktır: User, Product, Order, Invoice. Sonra bu varlıklar arasındaki ilişkileri belirleyin: bir Order birden fazla Product içerir, bir User birden fazla Order'a sahiptir.

İlişkileri modelleme konusunda iki yaklaşım vardır: iç içe kaynaklar (/users/123/orders) veya bağımsız kaynaklar (/orders?userId=123). Birincisi, sahiplik ilişkisini açıkça ifade eder; ikincisi ise daha esnek sorgulama imkanı sunar. E-ticaret senaryolarında genellikle hibrit yaklaşım kullanılır: temel CRUD için bağımsız, sahiplik bağlamı gerektiğinde iç içe.

Alt kaynaklar (sub-resources) da modellemenin parçasıdır. /products/456/reviews gibi bir yapı, ürünün yorumlarını mantıksal olarak gruplar. Ancak derin iç içe geçme (/users/123/orders/456/items/789) kaçınılmalıdır; genellikle iki seviye yeterlidir.

5. URI Tasarımı ve Versiyonlama Örnekleri

Tutarlı URI tasarımı, API'nizin kullanılabilirliğini belirler. Küçük harf kullanın, çoğul isimler tercih edin, tire (-) kullanın (alt çizgi (_) yerine). Sorgu parametreleri filtreleme, sıralama ve sayfalama için kullanılır: /products?category=electronics&sort=price&page=2.

Versiyonlama stratejileri arasında URL tabanlı (/v1/users), header tabanlı (Accept: application/vnd.api.v1+json) ve query parametreli (?version=1) yaklaşımlar bulunur. URL tabanlı en yaygın ve anlaşılır olanıdır; geliştirici endpoint'i görür görmez versiyonu bilir. Ancak büyük değişikliklerde (breaking changes) yeni versiyon, küçük değişikliklerde geriye dönük uyumluluk tercih edilmelidir.

# URL tabanlı versiyonlama
GET /api/v1/users
GET /api/v2/users

# Header tabanlı versiyonlama
GET /api/users
Accept: application/vnd.noves.v2+json

6. HATEOAS ve Bağlantı Temelli Yönlendirme Teknikleri

HATEOAS (Hypermedia as the Engine of Application State), REST'in en az anlaşılan ama en güçlü kısıtlamalarından biridir. API yanıtlarında, mevcut kaynakla ilgili olası sonraki eylemlere bağlantılar (links) eklenir. Bu, API'yi kendi kendine belgelendiren (self-descriptive) bir hale getirir.

Örneğin, bir sipariş yanıtında pay, cancel ve track linkleri bulunabilir. Sipariş durumu "shipped" olduğunda pay linki kalkar, track linki eklenir. Bu dinamik yapı, istemcinin iş akışını API yanıtlarından öğrenmesini sağlar ve sert kodlanmış URL'leri ortadan kaldırır. Spring HATEOAS ve JSON:API spesifikasyonu bu yaklaşımı destekler.

{
  "id": 42,
  "status": "pending",
  "total": 150.00,
  "_links": {
    "self": { "href": "/api/v1/orders/42" },
    "pay": { "href": "/api/v1/orders/42/pay", "method": "POST" },
    "cancel": { "href": "/api/v1/orders/42", "method": "DELETE" }
  }
}

7. Görselleştirme ve Dokümantasyon: OpenAPI, Swagger, Postman

API dokümantasyonu, geliştirici deneyiminin (DX) temel taşıdır. İyi dokümante edilmiş bir API, entegrasyon süresini günlerden saatlere indirir. Modern yazılım ajanslarında dokümantasyon, kod yazıldıktan sonra eklenen bir iş değil, tasarım aşamasının parçasıdır. OpenAPI, Swagger ve Postman bu alandaki üç temel araçtır.

Dokümantasyonun amacı sadece endpoint listesi sunmak değil, iş akışları, hata senaryoları ve kimlik doğrulama mekanizmalarını da açıklamaktır. Interaktif dokümantasyon, geliştiricinin API'yi doküman içinde test etmesine olanak tanır; bu, entegrasyon sürecindeki sürtünmeyi minimuma indirir.

8. OpenAPI Nedir ve Nasıl Kullanılır

OpenAPI Specification (OAS), REST API'lerini tanımlamak için kullanılan standart bir formattır. YAML veya JSON olarak yazılır ve endpoint'leri, parametreleri, yanıt şemalarını, kimlik doğrulama yöntemlerini ve hata kodlarını tanımlar. OpenAPI 3.1, JSON Schema ile tam uyumluluk sunar.

OpenAPI spesifikasyonu, contract-first geliştirme yaklaşımının temelidir. Önce API sözleşmesi yazılır, sonra hem sunucu hem istemci bu sözleşmeye göre geliştirilir. Bu, frontend ve backend ekiplerinin paralel çalışmasını sağlar. Araçlar otomatik olarak sunucu stub'ları, istemci SDK'ları ve validatörler üretebilir.

openapi: 3.0.3
info:
  title: E-ticaret API
  version: 1.0.0
paths:
  /products:
    get:
      summary: Ürün listesi
      responses:
        '200':
          description: Başarılı
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Product'

9. Swagger UI ile Interaktif Dokümantasyon Örnekleri

Swagger UI, OpenAPI spesifikasyonunu görsel, interaktif bir arayüze dönüştüren araçtır. Geliştirici, tarayıcıda endpoint'leri görebilir, parametreleri doldurabilir ve "Try it out" butonuyla gerçek API çağrısı yapabilir. Bu, Postman koleksiyonu oluşturmaya gerek kalmadan hızlı test imkanı sunar.

Swagger UI'yi projeye entegre etmek için swagger-ui-express (Node.js) veya springdoc-openapi (Java) gibi kütüphaneler kullanılır. API değiştiğinde dokümantasyon otomatik güncellenir; bu, dokümantasyonun kodla senkronize kalmasını sağlar. Swagger UI, aynı zamanda API gateway'lerde ve mikroservis mimarilerinde merkezi dokümantasyon portalı olarak kullanılabilir.

10. Postman Koleksiyonları ve Otomatik Test Senaryoları

Postman, API geliştirme ekosisteminin vazgeçilmez aracıdır. Koleksiyonlar (collections), ilgili API çağrılarını gruplar; environment'lar ise farklı ortamlar (development, staging, production) için değişken tanımlamanızı sağlar. Postman'in gerçek gücü, test senaryoları ve CI/CD entegrasyonundadır.

Postman testleri, JavaScript ile yazılır ve her çağrı sonrası yanıtın yapısını, durum kodunu ve performansını doğrular. Newman CLI aracıyla bu koleksiyonlar CI/CD pipeline'ında otomatik çalıştırılır. Contract testleri, API'nin OpenAPI spesifikasyonuna uygunluğunu kontrol eder; bu, regresyon testlerinin önemli bir parçasıdır.

// Postman test örneği
pm.test("Status code is 200", () => {
    pm.response.to.have.status(200);
});
pm.test("Response has required fields", () => {
    const json = pm.response.json();
    pm.expect(json).to.have.property('id');
    pm.expect(json).to.have.property('email');
});

11. Dokümantasyonda Örnek Yük ve Şema Doğrulama Detayları

İyi API dokümantasyonu, sadece endpoint listesi değil, gerçekçi örnek yükler (request/response examples) ve JSON Schema doğrulama kuralları içerir. Örnek yükler, geliştiricinin API'yi anlamasını kolaylaştırır; şema doğrulama ise hatalı istekleri erken aşamada yakalar.

JSON Schema, veri tiplerini, zorunlu alanları, formatları (email, date-time) ve enum değerlerini tanımlar. OpenAPI 3.x içinde examples alanı, her endpoint için birden fazla senaryo (başarılı, hatalı, edge case) tanımlamanıza olanak tanır. Şema doğrulama, hem sunucu tarafında (input validation) hem istemci tarafında (SDK generation) kullanılır.

{
  "example": {
    "id": 42,
    "email": "user@example.com",
    "role": "customer"
  },
  "schema": {
    "type": "object",
    "required": ["email", "role"],
    "properties": {
      "id": { "type": "integer" },
      "email": { "type": "string", "format": "email" },
      "role": { "enum": ["admin", "customer", "vendor"] }
    }
  }
}

12. Yerleşim ve Mimari: Monolit, Mikroservis ve Gateway Desenleri

API mimarisi, uygulamanızın ölçeklenebilirliğini ve bakımını doğrudan etkiler. Monolitik mimari, tek bir kod tabanında tüm işlevleri barındırır; geliştirme hızlıdır ama ölçeklenmesi zordur. Mikroservis mimarisi, her iş alanını bağımsız servislere ayırır; esneklik sunar ama operasyonel karmaşıklığı artırır. Gateway deseni, bu iki dünya arasında köprü kurar.

Mimari seçimi, ekibinizin boyutuna, domain karmaşıklığına ve trafik beklentilerine bağlıdır. Yeni başlayan bir SaaS ürününde monolit ile başlamak, gerektiğinde servis ayrıştırmak (strangler fig pattern) en pratik yaklaşımdır. API Gateway, istemcinin mikroservislerin karmaşıklığını görmemesini sağlayan fasadedir.

13. Mikroservis Mimarisi Nedir ve Avantajları

Mikroservis mimarisi, uygulamayı küçük, bağımsız ve iş alanına göre sınırlandırılmış (bounded context) servislere böler. Her servis kendi veritabanını, teknoloji stack'ini ve deployment sürecini yönetir. "Separation of concerns" ilkesinin en saf uygulamasıdır.

Avantajları çoktur: bağımsız ölçeklendirme (sadece yoğun servisi scale edersiniz), teknoloji çeşitliliği (her servis için en uygun dil), hata izolasyonu (bir servis çökerse diğerleri ayakta kalır) ve paralel geliştirme (farklı ekipler farklı servislerde çalışır). Ancak dağıtık sistemlerin karmaşıklığı, transaction yönetimi ve servisler arası iletişim maliyeti de göz önünde bulundurulmalıdır.

14. API Gateway Nasıl Kullanılır; Yönlendirme ve Güvenlik

API Gateway, tüm istemci çağrılarının ilk durağıdır. Yönlendirme (routing), isteği doğru mikroservise yönlendirir: /orders/* → Order Service, /users/* → User Service. Bu, istemcinin tek bir URL bilmesi yeterli olmasını sağlar; arka plandaki servis yapısı değişse bile istemci etkilenmez.

Gateway aynı zamanda cross-cutting concerns'ları merkezi yönetir: kimlik doğrulama (JWT validation), rate limiting, istek/yanıt dönüşümü ve SSL termination. Kong, AWS API Gateway, Azure API Management ve Nginx bu alandaki popüler çözümlerdir. Gateway'de yapılan güvenlik kontrolleri, her servisi ayrı ayrı korumaya göre daha verimlidir.

# Nginx Gateway örneği
location /api/v1/ {
    auth_request /auth;
    proxy_pass http://backend_cluster;
    proxy_set_header X-User-Id $user_id;
    
    # Rate limiting
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
}

15. Monolitten Servis Ayrıştırma Örnekleri

Monolitik uygulamayı birdenbire mikroservislere bölmek risklidir. Strangler Fig deseni, yavaş ve güvenli bir geçiş sunar: yeni özellikleri yeni servis olarak yazarsınız, eski monolit üzerindeki ilgili modülü "sarar" (strangle) ve zamanla monoliti emekli edersiniz.

Örneğin, bir e-ticaret monolitinde önce "bildirim servisi"ni (email, SMS, push) ayırabilirsiniz. Bu servis, monolitin olaylarını (order_placed, user_registered) dinler ve bağımsız çalışır. Sonra "ödeme servisi", "stok servisi" sırasıyla izler. Her ayrıştırma adımında, veri tutarlılığı için Saga pattern (orchestration veya choreography) kullanılır. CI/CD pipeline'ları her yeni servis için ayrı deployment süreçleri oluşturur.

16. Gelişmiş Özellikler: Versiyonlama, Hata Yönetimi, Sözleşme Tabanlı Gelişim

API'leriniz büyüdükçe, gelişmiş özellikler hayati önem kazanır. Versiyonlama, mevcut istemcileri kırılmadan yeni özellikler eklemenizi sağlar. Hata yönetimi, tutarlı ve anlamlı hata yanıtlarıyla geliştirici deneyimini korur. Sözleşme tabanlı gelişim (Contract-First), API'nin tasarım ve uygulama arasındaki boşluğu kapatır.

Bu üç konu, API'nizin "olgunluk seviyesini" belirler. Startup aşamasında hızlı hareket etmek önemlidir, ama enterprise düzeyde tutarlılık ve öngörülebilirlik kritiktir. Bu bölümde, her iki dünyanın en iyi pratiklerini harmanlıyoruz.

17. API Versiyonlama Stratejileri ve Örnekleri

Versiyonlama stratejisi seçimi, API'nizin kullanıcı kitlesine ve değişim hızına bağlıdır. URL tabanlı versiyonlama (/v1/, /v2/) en yaygın ve anlaşılır olanıdır. Header tabanlı versiyonlama (Accept: application/vnd.api.v1+json) daha "RESTful" kabul edilir ama keşfedilebilirliği azaltır. Query parametreli versiyonlama (?api-version=2) basittir ama URL'yi kirletir.

Semantic Versioning (SemVer) prensipleri API'lerde de uygulanabilir: major değişiklikler (breaking) yeni versiyon, minor değişiklikler (yeni özellikler) aynı versiyon, patch değişiklikleri (bugfix) şeffaftır. Sunset header'ları (Sunset: Sat, 31 Dec 2026 23:59:59 GMT) kullanıcıları eski versiyonun kaldırılacağı konusunda önceden uyarır.

# Versiyon bilgisi header'da
GET /users/42
Accept: application/json
API-Version: 2

# Yanıt
HTTP/1.1 200 OK
Sunset: Sat, 31 Dec 2026 23:59:59 GMT
Deprecation: true

18. Hata Kodları, Hata Gövdesi Formatı ve Yeniden Deneme Politikaları

Tutarlı hata yanıtları, API'nizin güvenilirliğini artırır. RFC 7807 (Problem Details for HTTP APIs) standardı, hata yanıtları için application/problem+json formatını tanımlar. Bu format, type (hata dokümanının URL'i), title (insan tarafından okunabilir özet), status (HTTP durum kodu), detail (spesifik açıklama) ve instance (hata oluşan URI) alanlarını içerir.

Yeniden deneme politikaları (retry policies), geçici hatalar (5xx, timeout, rate limit) karşısında istemcinin ne yapacağını belirler. Exponential backoff, her deneme arasındaki bekleme süresini katlayarak artırır. Jitter (rastgele gürültü eklemek), aynı anda binlerce istemcinin aynı anda yeniden denemesini önler. Retry-After header'ı, istemciye ne kadar beklemesi gerektiğini söyler.

{
  "type": "https://api.example.com/errors/insufficient-funds",
  "title": "Yetersiz Bakiye",
  "status": 402,
  "detail": "Hesabınızda 150 TL eksik. Mevcut bakiye: 50 TL.",
  "instance": "/orders/42/payment"
}

19. Sözleşme Tabanlı Geliştirme (Contract-First) Nasıl Uygulanır

Contract-First yaklaşımında, API sözleşmesi (OpenAPI/Swagger) kod yazılmadan önce tasarlanır. Bu sözleşme, frontend ve backend ekipleri arasında ortak bir dil görevi görür. Tasarım aşamasında endpoint'ler, parametreler, yanıt şemaları ve hata senaryoları tartışılır; bu, geliştirme sürecindeki "bu alan eksik" sorunlarını minimize eder.

Araçlar bu süreci otomatize eder: Stoplight Studio veya Swagger Editor ile sözleşme görsel olarak tasarlanır. Sonra openapi-generator sunucu stub'ları (Spring, Node.js, FastAPI) ve istemci SDK'ları (TypeScript, Dart, Kotlin) üretir. Consumer-Driven Contract (CDC) testleri, istemcinin beklediği sözleşmeyi sunucunun karşıladığını doğrular.

20. Sözleşme Testleri ve CI Entegrasyonu Teknik Detayları

Sözleşme testleri, API'nin OpenAPI spesifikasyonuna uygunluğunu otomatik olarak doğrular. Spring Cloud Contract, Pact veya Schemathesis gibi araçlar, hem sunucu tarafında (provider tests) hem istemci tarafında (consumer tests) çalıştırılır. Pact, consumer-driven contract testing'in en popüler aracıdır; istemci kendi beklentilerini "pact" dosyası olarak yazar, sunucu bu dosyaya karşı test edilir.

CI/CD entegrasyonunda, sözleşme testleri her pull request'te çalıştırılır. Pact Broker, farklı servislerin sözleşmelerini merkezi olarak yönetir ve "can I deploy?" sorusuna otomatik yanıt verir. Bu, mikroservis mimarilerinde bağımsız deployment'ların güvenliğini sağlar. Contract testleri, unit testlerden daha yavaş ama entegrasyon testlerinden daha hızlıdır; bu yüzden CI pipeline'ının orta aşamalarında konumlandırılır.

# GitHub Actions - Contract Test örneği
- name: Run Contract Tests
  run: |
    pact-verifier \
      --provider-base-url http://localhost:8080 \
      --pact-broker-base-url https://pact.noves.digital \
      --provider "order-service" \
      --provider-app-version ${{ github.sha }}

21. Performans ve Ölçeklenebilirlik: Önbellekleme, Rate Limiting, CDN

API performansı, kullanıcı deneyiminin doğrudan belirleyicisidir. Bir mobil uygulama, API yanıtını 500ms'de alıyorsa kullanıcı akışı kesintisiz devam eder; 3 saniye bekliyorsa kullanıcı kaybı başlar. Önbellekleme, rate limiting ve CDN, performans optimizasyonunun üç temel direğidir.

Bu stratejiler sadece hız değil, maliyet optimizasyonu da sağlar. Önbellek isabet oranı (cache hit ratio) %80'in üzerindeyse, veritabanı yükü ciddi şekilde azalır. Rate limiting, kötü niyetli veya hatalı istemcilerin sistem kaynaklarını tüketmesini önler. CDN, statik içerikleri ve cache'lenebilir API yanıtlarını kullanıcıya coğrafi olarak yakın noktalardan sunar.

22. Önbellekleme Stratejileri ve Cache-Control Örnekleri

HTTP önbellekleme, Cache-Control header'larıyla yönetilir. max-age (saniye cinsinden önbellek süresi), no-cache (her seferinde sunucuya doğrulama), no-store (hiç önbellekleme yapma), private (sadece tarayıcı önbelleği) ve public (ara proxy'ler de önbellekleyebilir) direktifleri kullanılır.

API önbellekleme stratejileri: Cache-Aside (uygulama önbelleği yönetir), Read-Through (önbellek kütüphanesi yönetir), Write-Through (veri yazılırken önbellek de güncellenir) ve Write-Behind (asenkron güncelleme). Redis ve Memcached, API önbellekleme için en yaygın araçlardır. ETags ve Last-Modified header'ları, koşullu isteklerle (If-None-Match) bant genişliği tasarrufu sağlar.

# Yanıt header'ları
Cache-Control: public, max-age=3600, stale-while-revalidate=86400
ETag: "abc123"
Vary: Accept-Encoding, Authorization

# Koşullu istek
GET /products/42
If-None-Match: "abc123"

# 304 Not Modified (bant genişliği tasarrufu)
HTTP/1.1 304 Not Modified

23. Rate Limiting ve Throttling Nasıl Uygulanır

Rate limiting, belirli bir zaman penceresindeki istek sayısını sınırlar. Token Bucket algoritması, sabit hızda token üretir; her istek bir token tüketir. Leaky Bucket, kuyruğa alınan istekleri sabit hızda işler. Fixed Window, basit ama "thundering herd" sorununa açıktır; Sliding Window Log ise daha adil dağıtım sunar.

HTTP 429 (Too Many Requests) durum kodu, limit aşıldığında döndürülür. X-RateLimit-Limit (toplam limit), X-RateLimit-Remaining (kalan istek) ve X-RateLimit-Reset (limitin sıfırlanacağı zaman) header'ları, istemciye durumu şeffaf şekilde bildirir. API Gateway'ler (Kong, AWS API Gateway) ve middleware kütüphaneleri (Express express-rate-limit, FastAPI slowapi) bu işlevi kolaylaştırır.

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

24. CDN ve Edge Caching ile Gecikme Azaltma Örnekleri

CDN (Content Delivery Network), içeriği kullanıcıya coğrafi olarak en yakın edge sunucusundan sunar. API yanıtları için CDN kullanımı, özellikle okuma yoğun ve cache'lenebilir endpoint'lerde etkilidir. Cloudflare, AWS CloudFront, Fastly ve Akamai bu alandaki başlık çözümlerdir.

Edge caching, CDN'in API yanıtlarını önbelleklemesidir. Ancak dikkatli kullanılmalıdır: kullanıcıya özel veriler (JWT ile kimlik doğrulama gerektiren) cache'lenmemelidir. Vary: Authorization header'ı, farklı kullanıcılar için farklı önbellek versiyonları oluşturur. GraphQL sorguları için CDN kullanımı daha karmaşıktır; GET tabanlı query'ler ve query hash'leri ile cache key oluşturulabilir.

# Edge cache için uygun yanıt
GET /api/v1/products?category=electronics
Cache-Control: public, max-age=300, s-maxage=600
Vary: Accept-Encoding
CDN-Cache-Control: max-age=600

25. Güvenlik ve Uyumluluk: Kimlik Doğrulama, Yetkilendirme, GDPR

API güvenliği, sadece teknik bir konu değil, iş sürekliliği ve hukuki uyumluluk meselesidir. Bir veri ihlali, hem itibar kaybına hem GDPR kapsamında ciddi para cezalarına yol açabilir. Kimlik doğrulama (authentication), yetkilendirme (authorization) ve veri koruma, güvenlik üçgeninin köşeleridir.

Modern API güvenliği, "zero trust" prensibine dayanır: hiçbir istemci veya servis varsayılan olarak güvenilir değildir. Her çağrı kimlik doğrulama ve yetkilendirme kontrolünden geçer. TLS 1.3, tüm iletişimin şifrelenmesini sağlar. API anahtarları, JWT token'ları ve OAuth 2.0, kimlik doğrulama katmanlarını oluşturur.

26. OAuth 2.0 ve JWT Nedir; Nasıl Kullanılır

OAuth 2.0, üçüncü taraf uygulamaların kullanıcı adına kaynaklara erişimini yetkilendiren standart bir protokoldür. Authorization Code flow (web uygulamaları), Client Credentials flow (servis-servis iletişim), Implicit flow (eski, artık önerilmez) ve Device Code flow (TV/IoT cihazları) gibi grant tipleri sunar.

JWT (JSON Web Token), kimlik bilgilerini taşıyan kompakt, URL-güvenli token formatıdır. Header (algoritma), Payload (claims) ve Signature (imza) bölümlerinden oluşur. Access token'lar kısa ömürlüdür (15 dakika), refresh token'lar uzun ömürlüdür (7-30 gün). JWT'ler stateless'tır; sunucu token'ı doğrulamak için veritabanı sorgusu yapmaz, bu performans optimizasyonu sağlar. Ancak token iptali (revocation) karmaşıktır; bu durumda token blacklist veya kısa ömürlü token stratejisi kullanılır.

// JWT Payload (decoded)
{
  "sub": "user_42",
  "iss": "https://auth.noves.digital",
  "aud": "api.noves.digital",
  "exp": 1683724800,
  "scope": "read:orders write:profile",
  "tenant_id": "acme_corp"
}

27. Rol Tabanlı Erişim Kontrolü (RBAC) ve İzin Yönetimi Örnekleri

RBAC, kullanıcılara roller atanması ve bu rollerin izinlerle eşleştirilmesi prensibine dayanır. Örneğin: admin (tüm kaynaklara CRUD), manager (okuma + kendi departmanına yazma), customer (sadece kendi verileri). Bu model, basit ve yönetilebilirdir ama kaynak bazlı ince taneli (fine-grained) kontrol gerektiğinde yetersiz kalabilir.

ABAC (Attribute-Based Access Control) daha esnektir: kullanıcının departmanı, kaynağın sahibi, zaman, konum gibi attribute'lar karar vermede kullanılır. Örneğin: "sadece Pazartesi-Cuma 09:00-18:00 arası, İstanbul ofisinden, finans departmanı çalışanları fatura görüntüleyebilir." Policy Engine'ler (OPA - Open Policy Agent, AWS IAM) bu karmaşık kuralları değerlendirir.

// RBAC claim örneği (JWT içinde)
{
  "roles": ["customer", "premium"],
  "permissions": [
    "orders:read",
    "orders:create",
    "invoices:read"
  ],
  "tenant": "shop_123"
}

28. Veri Koruma ve Uyumluluk (GDPR) İçin API Tasarım Önerileri

GDPR ve benzeri düzenlemeler (CCPA, KVKK), API tasarımını doğrudan etkiler. Veri minimizasyonu prensibi, API'nin sadece gerekli veriyi döndürmesini gerektirir. fields query parametresi (/users?fields=id,email), istemcinin sadece ihtiyaç duyduğu alanları almasını sağlar; bu hem performans hem gizlilik açısından iyidir.

Veri silme hakkı (right to be forgotten), API'de "hard delete" veya "anonymization" endpoint'leri gerektirir. Veri taşınabilirliği (data portability), JSON/CSV export endpoint'leri ile sağlanır. Consent yönetimi, kullanıcının hangi verilerinin hangi amaçla işlendiğini API üzerinden kontrol etmesini sağlar. Loglama ve audit trail, veri işleme faaliyetlerinin kaydını tutar; bu kayıtlar 6 yıl saklanmalıdır.

# Veri minimizasyonu
GET /users/42?fields=id,email,username

# GDPR silme isteği
DELETE /users/42/gdpr
X-GDPR-Reason: "Right to erasure - Article 17"

# Veri taşınabilirliği
GET /users/42/export?format=json

29. Güvenlik Testleri: Pen-Test ve Otomatik Güvenlik Taramaları

API güvenlik testleri, manuel penetration testing ve otomatik taramaların birleşimidir. OWASP API Security Top 10, API'lerdeki en kritik güvenlik risklerini listeler: Broken Object Level Authorization (BOLA), Broken Authentication, Excessive Data Exposure, Lack of Resources & Rate Limiting, Broken Function Level Authorization, Mass Assignment, Security Misconfiguration, Injection, Improper Assets Management, Insufficient Logging & Monitoring.

Otomatik araçlar: OWASP ZAP (açık kaynak), Burp Suite (profesyonel), Postman güvenlik test koleksiyonları ve API-specific scanner'lar (42Crunch, Escape). CI/CD entegrasyonunda, nuclei veya zap-baseline gibi araçlar her deployment öncesi çalıştırılır. Fuzzing testleri, rastgele veya anormal girdilerle API'nin davranışını test eder; buffer overflow ve injection zafiyetlerini yakalar.

30. Uygulama Senaryoları: Web Geliştirme, Responsive Tasarım, E-ticaret, SaaS, UI/UX

API'ler teoride kalmaz; gerçek dünya senaryolarında şekillenir. Web geliştirme, mobil uygulama, e-ticaret, SaaS ve UI/UX odaklı tasarım, farklı API gereksinimleri doğurur. Bu bölümde, bu senaryolara özgü pratik yaklaşımları ele alıyoruz.

Cross-platform geliştirme (Flutter, React Native), tek bir API'nin iOS, Android ve Web istemcilerine hizmet etmesini gerektirir. Bu durumda API yanıt formatının platform-agnostic olması kritiktir. E-ticaret API'leri, stok tutarlılığı, ödeme güvenliği ve sipariş akışı yönetimi gibi özel zorluklar sunar.

31. Web Geliştirme İçin REST API Entegrasyon Örnekleri

Modern web uygulamalarında (React, Next.js, Vue), API entegrasyonu veri katmanının merkezidir. React Query (TanStack Query), SWR veya Redux Toolkit Query gibi kütüphaneler, API çağrılarını cache'ler, yeniden deneme politikalarını yönetir ve loading/error state'leri soyutlar. Bu, geliştiricinin veri çekme mantığı yerine UI/UX odaklanmasını sağlar.

Next.js 14 App Router ile Server Components, API çağrılarını sunucu tarafında yapar; bu, istemciye JSON yerine render edilmiş HTML gönderir ve performans optimizasyonu sağlar. Ancak interaktif bileşenler (Client Components) hala API çağrısı yapar. Streaming SSR, API yanıtının parça parça gelmesini ve sayfanın kademeli olarak render edilmesini sağlar.

// React Query ile API entegrasyonu
const { data, isLoading } = useQuery({
  queryKey: ['products', category],
  queryFn: () => fetch(`/api/products?category=${category}`).then(r => r.json()),
  staleTime: 5 * 60 * 1000, // 5 dakika cache
  retry: 3,
});

32. Responsive Ön Yüzlerde API Kullanım Örnekleri ve Performans İpuçları

Mobil öncelikli (mobile-first) tasarımda, API yükü kritiktir. Küçük ekranlarda daha az veri gösterilir; bu nedenle API'nin fields parametresiyle sadece gerekli alanları döndürmesi önemlidir. Pagination ve infinite scroll, mobil cihazlarda bellek yönetimini optimize eder.

Görsel optimizasyonu için API, resim URL'lerini farklı boyutlarda sunmalıdır: image_url?w=400 (mobil), image_url?w=800 (tablet), image_url?w=1200 (desktop). WebP/AVIF format desteği, bant genişliğini %30-50 azaltır. Skeleton loading ve placeholder'lar, API yanıtı gelene kadar kullanıcıya geri bildirim sunar; bu, kullanıcı deneyiminin algılanan hızını artırır.

# Responsive görsel isteği
GET /api/products/42/images?w=400&format=webp

# Hafifletilmiş yanıt (mobil için)
GET /api/products?fields=id,name,price,thumbnail&page_size=10

33. E-ticaret Platformlarında Sipariş ve Stok API Senaryoları

E-ticaret API'leri, iş akışı karmaşıklığıyla öne çıkar. Sipariş akışı: cart oluşturma → adres seçimi → ödeme → stok rezervasyonu → sipariş onayı → kargolama. Her adım, farklı servisler arası koordinasyon gerektirir. Stok tutarlılığı, race condition'ları önlemek için optimistic locking (version numarası) veya pessimistic locking (veritabanı kilitleri) ile sağlanır.

Ödeme API entegrasyonu (Stripe, iyzico), idempotency key kullanır: aynı ödeme isteği tekrarlanırsa (kullanıcı butona iki kez basarsa), sadece bir işlem gerçekleşir. Webhook'lar, ödeme durumu değişikliklerini asenkron olarak bildirir. Sipariş durumu makinesi (state machine), geçersiz durum geçişlerini (örneğin "shipped" bir siparişin "cancelled" olması) API seviyesinde engeller.

// Sipariş durumu geçişi (state machine)
{
  "order_id": "ORD-2024-001",
  "status": "payment_pending",
  "allowed_transitions": ["paid", "cancelled"],
  "_links": {
    "pay": { "href": "/orders/ORD-2024-001/pay", "method": "POST" },
    "cancel": { "href": "/orders/ORD-2024-001", "method": "DELETE" }
  }
}

34. SaaS Ürünleri ve Çok Kiracılı (Multi-Tenant) API Tasarımı

Multi-tenant SaaS mimarisi, tek bir kod tabanı ve altyapıyla birden fazla müşteriye (tenant) hizmet sunar. Veri izolasyonu stratejileri: Shared Database/Shared Schema (tenant_id kolonuyla), Shared Database/Separate Schema (her tenant ayrı schema), Separate Database (her tenant ayrı veritabanı). İlk seçenek en basit ama en az izole; son seçenek en izole ama en maliyetli.

API'de tenant izolasyonu, JWT token içindeki tenant_id claim'i veya subdomain (acme.api.saasapp.com) ile sağlanır. Middleware, her isteğin tenant bağlamını doğrular ve veritabanı sorgularına otomatik WHERE tenant_id = ? ekler. Rate limiting tenant bazlı olmalıdır: bir tenant'ın yoğun kullanımı diğerlerini etkilememeli. White-label özellikleri, API yanıtlarında tenant'a özel branding bilgileri döndürür.

# Multi-tenant API isteği
GET /api/v1/invoices
Host: acme-corp.saasapp.com
Authorization: Bearer eyJ... (tenant_id: "acme_corp" içerir)

# Tenant bazlı rate limit
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 987
X-Tenant-ID: acme_corp

35. UI/UX Odaklı API Tasarımı: Hızlı Veri Yükleme ve Önbellek Stratejileri

API tasarımı, sadece backend mühendisliği değil, kullanıcı deneyiminin bir uzantısıdır. "API-first UX" yaklaşımında, ekran tasarımı yapılmadan önce API endpoint'leri ve yanıt yapıları bellidir. Bu, frontend geliştiricinin mock data ile çalışmasını ve backend hazır olmadan UI prototipi oluşturmasını sağlar.

Hızlı veri yükleme için BFF (Backend for Frontend) pattern kullanılır: mobil uygulama için hafifletilmiş, web uygulaması için zenginleştirilmiş API'ler. GraphQL, istemcinin ihtiyaç duyduğu alanları tek çağrıda almasını sağlar; bu, N+1 sorununu çözer. Önbellek stratejileri: SWR (stale-while-revalidate), optimistic UI (API yanıtı gelmeden UI güncelleme) ve prefetching (kullanıcı hover ettiğinde veriyi önceden çekme).

// Optimistic UI örneği (React)
const mutation = useMutation({
  mutationFn: updateProfile,
  onMutate: async (newData) => {
    await queryClient.cancelQueries({ queryKey: ['profile'] });
    const prev = queryClient.getQueryData(['profile']);
    queryClient.setQueryData(['profile'], newData); // Anında UI güncelle
    return { prev };
  },
  onError: (err, newData, context) => {
    queryClient.setQueryData(['profile'], context.prev); // Hata durumunda geri al
  },
});

36. Geliştirme Araçları ve Test: CI/CD, Mocking, İzleme

API geliştirme süreci, kod yazmaktan çok daha fazlasını içerir. Sürekli entegrasyon (CI), sürekli dağıtım (CD), mock sunucular, contract testleri ve izleme (observability), profesyonel ekiplerde standart pratiklerdir. Bu araçlar, hataları erken yakalar, deployment riskini azaltır ve üretimdeki sorunları hızlı teşhis eder.

Agile geliştirme süreçlerinde, 2 haftalık sprintlerde API endpoint'leri tasarlanır, mock'lanır, geliştirilir ve test edilir. CI/CD pipeline'ı, her commit'te otomatik testleri çalıştırır, kod kalitesini kontrol eder ve başarılı olduğunda otomatik deployment yapar.

37. CI/CD Boru Hatlarında API Sürümleme ve Dağıtım Örnekleri

CI/CD pipeline'ında API sürümleme, semantic versioning ve Git etiketleriyle yönetilir. Her major versiyon için ayrı deployment path'leri (/v1/, /v2/) veya feature flag'ler kullanılır. Blue-green deployment, yeni versiyonu trafiğin %1'iyle test edip sorun yoksa %100'e çıkarır. Canary deployment, trafiği kademeli olarak yeni versiyona yönlendirir.

API değişiklikleri, OpenAPI diff araçlarıyla (openapi-diff, bump.sh) otomatik olarak analiz edilir. Breaking change tespit edilirse pipeline durur ve manuel onay gerektirir. Database migration'lar, API deployment'ından önce veya sonra koordine edilir; backward-compatible migration stratejisi (expand-contract pattern) kullanılır.

# GitHub Actions - API Deployment
jobs:
  deploy:
    steps:
      - name: API Diff Check
        run: openapi-diff openapi.yaml openapi-prev.yaml
      - name: Deploy to Staging
        run: kubectl apply -f k8s/api-deployment.yaml
      - name: Smoke Tests
        run: newman run postman/collection.json -e postman/staging.json
      - name: Canary Deploy
        run: kubectl set image deployment/api api=api:v2 --record

38. Mock Sunucular ve Contract Mocking Nasıl Kurulur

Mock sunucular, backend hazır olmadan frontend geliştirmeyi mümkün kılar. WireMock, JSON Server, MirageJS ve MSW (Mock Service Worker) popüler araçlardır. Contract mocking, OpenAPI spesifikasyonundan otomatik mock yanıtları üretir; prism veya openapi-mock-server gibi araçlar bunu sağlar.

Mock'lar sadece statik yanıt değil, dinamik davranışlar da simüle edebilir: gecikme ekleme, hata senaryoları, pagination ve stateful mock'lar (bir POST sonrası GET aynı veriyi döner). E2E testlerde (Cypress, Playwright), MSW ile API çağrıları mock'lanır; bu, testlerin dış bağımlılıklardan izole olmasını sağlar ve test edilebilirliği artırır.

// MSW (Mock Service Worker) örneği
const handlers = [
  rest.get('/api/users', (req, res, ctx) => {
    return res(
      ctx.delay(150),
      ctx.status(200),
      ctx.json({ users: [{ id: 1, name: 'Ahmet' }] })
    );
  }),
  rest.post('/api/orders', (req, res, ctx) => {
    return res(ctx.status(201), ctx.json({ orderId: 'ORD-001' }));
  }),
];

39. İzleme ve Telemetri: Logging, Tracing, Metrik Örnekleri

Observability üçlüsü: loglar (olay kayıtları), metrikler (sayısal ölçümler) ve trace'ler (istek akışı). Structured logging (JSON formatında), log aggregation araçları (ELK Stack, Splunk, Datadog) ile analiz edilir. Trace ID'ler, bir isteğin gateway'den database'e kadar olan yolculuğunu izler; OpenTelemetry standardı bu alanda evrenseldir.

API metrikleri: latency (p50, p95, p99), hata oranı (error rate), throughput (RPS), availability (uptime). RED methodu (Rate, Errors, Duration) ve USE methodu (Utilization, Saturation, Errors) izleme stratejileri sunar. Alerting kuralları: p95 latency > 500ms veya error rate > 1% → PagerDuty/OpsGenie bildirimi. Distributed tracing, mikroservis mimarilerinde sorun teşhisini kolaylaştırır.

// Structured log örneği
{
  "timestamp": "2024-05-10T13:13:00Z",
  "level": "ERROR",
  "trace_id": "abc123",
  "span_id": "def456",
  "service": "order-service",
  "method": "POST",
  "path": "/api/v1/orders",
  "status": 500,
  "duration_ms": 2450,
  "error": "database_connection_timeout",
  "user_id": "user_42"
}

40. Canary ve Blue-Green Dağıtım Teknikleri İçin API Test Detayları

Canary deployment, yeni API versiyonunu trafiğin küçük bir yüzdesine (örneğin %5) sunar. Hata oranı ve latency izlenir; eşik değerleri aşılmazsa trafik %50, sonra %100'e çıkarılır. Istio, Linkerd gibi service mesh araçları, traffic splitting'i kolaylaştırır. Feature flag'ler (LaunchDarkly, Unleash), canary'yi kullanıcı segmentine göre (sadece beta kullanıcıları) yapmanızı sağlar.

Blue-green deployment, iki identik ortam (blue=aktif, green=yeni) arasında anında geçiş sunar. Veritabanı migration'ları, backward-compatible olmalıdır (yeni kolon ekleme, eski kolonu kullanmaya devam). API testleri: smoke test'ler (deployment sonrası kritik path'leri hızlı kontrol), synthetic monitoring (üretimdeki API'leri periyodik çağırma) ve chaos engineering (kasıtlı hata enjeksiyonu). API gateway'de circuit breaker pattern, yeni versiyonun başarısız olması durumunda otomatik fallback sağlar.

# Istio Canary örneği
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-canary
spec:
  http:
  - route:
    - destination:
        host: api
        subset: v1
      weight: 90
    - destination:
        host: api
        subset: v2
      weight: 10

41. Sonuç ve En İyi Uygulamalar: Tasarım İlkeleri, Ölçümler, Gelecek Trendler

Bu rehber boyunca REST API geliştirmenin tüm yığınını ele aldık: temel prensiplerden mikroservis mimarisine, güvenlikten performans optimizasyonuna, CI/CD'den izlemeye. Teknolojiler değişse de temel ilkeler sabittir: tutarlılık, öngörülebilirlik, güvenlik ve kullanıcı deneyimi odaklılık.

Noves Digital olarak gözlemlediğimiz en başarılı projeler, API'yi sadece teknik bir araç değil, ürünün bir parçası olarak gören ekipler tarafından geliştirilir. API dokümantasyonu, geliştirici pazarlama materyalidir. API performansı, kullanıcı memnuniyetidir. API güvenliği, marka itibarıdır.

42. REST API Tasarımında Okunabilirlik ve Tutarlılık İlkeleri

Tutarlılık, API'nizin en önemli özelliğidir. Tüm endpoint'ler aynı naming convention'u kullanmalı, aynı hata formatını dönmeli, aynı kimlik doğrulama mekanizmasını uygulamalıdır. Pagination her kaynakta aynı çalışmalı: page, per_page, total, total_pages. Sıralama her kaynakta aynı: sort=field:asc|desc.

İsimlendirme kuralları: çoğul isimler (/orders değil /order), kebab-case URL'ler (/order-items), snake_case JSON alanları (created_at), camelCase JavaScript SDK'ları için. Tutarlılık, API'nin "öğrenilebilirliğini" artırır; geliştirici bir endpoint'i öğrendiğinde diğerlerini tahmin edebilir. API Style Guide dokümanı, ekip içinde bu kuralları kodlaştırır.

43. Başarı Ölçümleri: SLA, Latency, Hata Oranı Nasıl İzlenir

API başarısı, teknik metriklerle ölçülür. SLA (Service Level Agreement), availability hedefini belirtir: %99.9 (yılda ~8 saat downtime), %99.99 (yılda ~52 dakika), %99.999 (yılda ~5 dakika). Latency percentilleri: p50 (medyan), p95 (%95'lik dilim), p99 (en yavaş %1). p95 < 200ms, p99 < 500ms hedefleri yaygındır.

Hata oranı (error rate), 5xx durum kodlarının toplam isteklere oranıdır; < 0.1% hedeflenir. Apdex score, kullanıcı memnuniyetini sayısal ifade eder: 1.0 (mükemmel), 0.5 (kabul edilebilir), 0.0 (kötü). SLO (Service Level Objective), SLA'dan daha katı iç hedeflerdir. Error budget, belirli bir dönemde kabul edilebilir hata miktarıdır; budget tükenince yeni feature geliştirme durur, sadece stabilizasyon yapılır.

# API SLA Örnekleri
Availability:     99.95% (yıllık)
Latency (p95):      < 300ms
Latency (p99):      < 800ms
Error Rate:         < 0.05%
Throughput:         10,000 RPS

44. Gelecek Trendler: GraphQL ile Hibrit Yaklaşımlar ve Adaptasyon Örnekleri

REST, evrensel standart olmaya devam ederken GraphQL, istemci-odaklı veri çekme ihtiyacını karşılar. Hibrit yaklaşımda, REST temel CRUD ve cache-friendly operasyonlar için kullanılır; GraphQL karmaşık sorgular, aggregation'lar ve istemci-özel veri ihtiyaçları için kullanılır. Bu, "best of both worlds" stratejisidir.

gRPC, servis-servis iletişiminde (mikroservisler arası) performans avantajı sunar: binary protobuf formatı, HTTP/2 multiplexing ve strong typing. REST ise dış istemciler (üçüncü taraf geliştiriciler, mobil uygulamalar) için daha uygun kalır. AsyncAPI, event-driven API'ler (WebSocket, Kafka, MQTT) için OpenAPI'nin karşılığıdır. Webhooks ve Server-Sent Events (SSE), gerçek zamanlı güncellemeler için REST'in tamamlayıcılarıdır.

45. API Göç Planı: REST'ten Hibrit Mimariye Geçiş Adımları

Mevcut REST API'nizi hibrit mimariye taşımak, büyük bir yeniden yazma değil, evrimsel bir süreçtir. Adım 1: mevcut REST API'yi stabilize edin ve OpenAPI spesifikasyonunu tamamlayın. Adım 2: GraphQL gateway kurun (Apollo Federation, Hasura); bu gateway, mevcut REST endpoint'leri GraphQL schema'ya dönüştürür (schema stitching). Adım 3: yeni özellikler için native GraphQL resolver'lar yazın; eski REST endpoint'ler yavaş yavaş emekli edilir.

Adım 4: servis-servis iletişiminde gRPC'yi değerlendirin; özellikle yüksek trafikli internal API'ler için. Adım 5: event-driven mimariye geçiş için AsyncAPI tanımlayın; Webhook'lar ve Kafka topic'leri ile async operasyonları destekleyin. Her adımda, istemcileri bilgilendirin, deprecation süreçleri yönetin ve geriye dönük uyumluluğu koruyun. API göçü, teknoloji değişimi değil, iş değerini artırma sürecidir.

# Hibrit API Gateway yapılandırması
# Apollo Federation - REST datasource
const { RESTDataSource } = require('@apollo/datasource-rest');

class ProductAPI extends RESTDataSource {
  baseURL = 'https://api.internal.com/v1/';
  
  async getProduct(id) {
    return this.get(`products/${id}`);
  }
}

Bu rehber, REST API geliştirmenin derinliklerine dalmayı amaçladı. Teknolojiler ve araçlar sürekli evriliyor, ancak sağlam temel prensipler her zaman geçerli kalıyor. Projelerinizde bu prensipleri uygularken, ekip büyüklüğünüze, domain karmaşıklığınıza ve kullanıcı beklentilerinize göre pragmatik kararlar almayı unutmayın. İyi kodlamalar!