• 
  [li]1. Client-Server Ayrımı: İstemci (client) ve sunucu (server) birbirinden bağımsız olmalıdır. İstemcinin kullanıcı arayüzü sorumluluğunu üstlenirken, sunucu veri depolama ve işleme sorumluluğunu üstlenir. Bu ayrım, her iki tarafın da bağımsız olarak geliştirilmesine ve ölçeklenmesine olanak tanır, böylece esnekliği artırır.[/li]
  [li]2. Durumsuzluk (Statelessness): Her istek (request), sunucu tarafından işlenmesi için gerekli tüm bilgiyi içermelidir. Sunucu, önceki isteklerden veya istemciden gelen herhangi bir oturum (session) bilgisini saklamamalıdır. Bu durum, sunucuların daha kolay ölçeklenmesine ve her isteğin bağımsız olarak ele alınmasına olanak tanır, bu da performansı ve güvenilirliği artırır.[/li]
  [li]3. Önbelleklenebilirlik (Cacheability): Sunucudan gelen yanıtlar açıkça önbelleklenebilir veya önbelleklenemez olarak işaretlenmelidir. Bu sayede istemciler, tekrarlanan istekler için sunucuya gitmek yerine önbellekten yanıt alabilir, bu da ağ trafiğini ve gecikmeyi azaltır.[/li]
  [li]4. Katmanlı Sistem (Layered System): İstemci, son sunucuya mı yoksa ara bir proxy veya yük dengeleyiciye mi bağlandığını bilmemelidir. Bu prensip, sistemin daha iyi ölçeklenebilmesini ve karmaşık altyapılarda bile performansını koruyabilmesini sağlar. Örneğin, bir API gateway veya CDN kullanmak, istemciye şeffaf bir şekilde hizmet verebilir.[/li]
  [li]5. Talep Üzerine Kod (Code on Demand) (Opsiyonel): Sunucu, istemciye çalıştırılabilir kod (örneğin JavaScript) sağlayabilir. Bu kısıtlama isteğe bağlıdır ve genellikle web tarayıcı tabanlı uygulamalarda dinamik işlevsellik sağlamak için kullanılır. Çoğu RESTful API bu prensibi kullanmaz.[/li]
  [li]6. Tek Tip Arayüz (Uniform Interface): Bu, REST mimarisinin en kritik prensibidir ve dört alt kısıtlamadan oluşur:
  • 
    [li]a. Kaynakların Tanımlanması (Resource Identification): Tüm kaynaklar, URI'lar (Uniform Resource Identifier) aracılığıyla benzersiz bir şekilde tanımlanmalıdır. Örneğin, bir kullanıcı kaynağı `/users/123` şeklinde bir URI ile temsil edilebilir.[/li]
    [li]b. Kaynakların Temsili Üzerinden İşlem Yapma (Manipulation of Resources Through Representations): İstemciler, bir kaynağın temsilini (örneğin JSON veya XML formatında) alarak ve değiştirerek kaynak üzerinde işlem yapabilirler. Sunucuya gönderilen temsil, kaynağın mevcut durumu hakkında yeterli bilgi içermelidir.[/li]
    [li]c. Kendi Kendini Tanımlayan Mesajlar (Self-Descriptive Messages): Her mesaj (istek veya yanıt), mesajın nasıl işleneceği hakkında yeterli bilgiyi içermelidir. HTTP başlıkları (Content-Type, Accept) bu bilgiyi sağlamak için kullanılır. Örneğin, bir yanıtın `Content-Type: application/json` başlığı, istemciye yanıt gövdesinin JSON formatında olduğunu bildirir.[/li]
    [li]d. HATEOAS (Hypermedia As The Engine of Application State): Bu kısıtlama, API'nizin yanıtlarında ilgili kaynaklara bağlantılar (hyperlinks) içermesi gerektiğini belirtir. İstemciler, bu bağlantıları izleyerek API içinde gezinmeli ve uygulamanın durumunu değiştirmelidir. Bu, API'yi daha keşfedilebilir ve esnek hale getirir. Örneğin, bir kullanıcı kaynağının yanıtı, kullanıcının siparişlerine veya profil düzenleme sayfasına bir bağlantı içerebilir.[/li]
  [/li]

• 
  [li]1. Kaynak Temelli URL Yapısı (Resource-Oriented URLs): URL'leriniz kaynakları temsil etmeli, fiilleri değil. Kaynak isimleri çoğul olmalı ve küçük harflerle yazılmalıdır. Kaynaklar arasındaki ilişkiler net olmalıdır.
  
  Kod:

  İyi:
  GET /urunler (Tüm ürünleri getir)
  GET /urunler/123 (ID'si 123 olan ürünü getir)
  POST /urunler (Yeni ürün oluştur)
  GET /kullanicilar/456/siparisler (456 numaralı kullanıcının siparişlerini getir)
  
  Kötü:
  GET /getAllProducts
  POST /createNewOrder
  GET /getProductById/123

  [/li]
  [li]2. Doğru HTTP Metotlarını Kullanma: HTTP metotları (fiiller), bir kaynak üzerinde gerçekleştirmek istediğiniz eylemi açıkça belirtmelidir.
  • 
    [li]GET: Kaynakları almak için kullanılır. Idempotent (birkaç kez çağrılsa da sunucu tarafında bir etki yaratmaz) ve safe (veri değiştirmez) olmalıdır.[/li]
    [li]POST: Yeni kaynak oluşturmak veya bir kaynağa veri göndermek için kullanılır. Idempotent değildir.[/li]
    [li]PUT: Mevcut bir kaynağı tamamen güncellemek veya yoksa oluşturmak için kullanılır. Idempotent'dir.[/li]
    [li]PATCH: Mevcut bir kaynağın kısmi güncellemesi için kullanılır. Idempotent değildir.[/li]
    [li]DELETE: Bir kaynağı silmek için kullanılır. Idempotent'dir.[/li]
  [/li]
  [li]3. Anlamlı HTTP Durum Kodları: Sunucudan gelen yanıtlar, işlemin başarısını veya başarısızlığını açıkça belirten standart HTTP durum kodlarını içermelidir. Bu, istemcinin yanıtı doğru bir şekilde yorumlamasına yardımcı olur.
  
  Kod:

  200 OK: İstek başarıyla tamamlandı.
  201 Created: Yeni bir kaynak başarıyla oluşturuldu (POST veya PUT sonrası).
  204 No Content: İstek başarıyla işlendi, ancak yanıt gövdesinde içerik yok (DELETE sonrası).
  400 Bad Request: İstemci isteği hatalı (geçersiz veri, eksik parametre).
  401 Unauthorized: Kimlik doğrulama başarısız oldu veya gerekli.
  403 Forbidden: Kimlik doğrulandı, ancak yetkisiz erişim.
  404 Not Found: Kaynak bulunamadı.
  405 Method Not Allowed: Kullanılan HTTP metodu kaynağa izin verilmiyor.
  500 Internal Server Error: Sunucu tarafında beklenmeyen bir hata oluştu.

  [/li]
  [li]4. Versiyonlama (Versioning): API'niz zamanla değişeceği için, uyumluluğu bozmadan değişiklikleri yönetmek için versiyonlama önemlidir. Yaygın yöntemler:
  • 
    [li]a. URI Versiyonlama: URL içinde versiyon numarasını belirtmek (örn: `/v1/users`). En yaygın ve anlaşılır yöntemdir.[/li]
    [li]b. Header Versiyonlama: Özel bir HTTP başlığı kullanarak versiyonu belirtmek (örn: `X-API-Version: 1`).[/li]
    [li]c. Accept Header Versiyonlama: `Accept` başlığında medya türü içinde versiyonu belirtmek (örn: `Accept: application/vnd.myapi.v1+json`).[/li]
  [/li]
  [li]5. Kimlik Doğrulama ve Yetkilendirme (Authentication & Authorization): API'nizi güvence altına almak için uygun mekanizmaları kullanın.
  • 
    [li]Kimlik Doğrulama (Authentication): Kullanıcının kim olduğunu doğrulamak (örn: OAuth 2.0, JWT, API Anahtarları).[/li]
    [li]Yetkilendirme (Authorization): Kimliği doğrulanmış kullanıcının belirli bir kaynağa veya eyleme erişim izni olup olmadığını belirlemek.[/li]
  [/li]
  [li]6. Hata Yönetimi (Error Handling): Hata durumlarında istemciye anlaşılır ve tutarlı bir hata yanıtı dönmek önemlidir. Hata mesajları insan tarafından okunabilir olmalı ve hata kodu, geliştirici mesajı gibi detayları içermelidir.
  
  Kod:

  HTTP/1.1 400 Bad Request
  Content-Type: application/json
  
  {
    "error": {
      "code": "INVALID_INPUT_DATA",
      "message": "Geçersiz giriş verisi. Lütfen 'ad' ve 'soyad' alanlarını kontrol edin.",
      "details": [
        {"field": "ad", "message": "'ad' alanı boş bırakılamaz."},
        {"field": "soyad", "message": "'soyad' alanı minimum 3 karakter olmalıdır."}
      ]
    }
  }

  [/li]
  [li]7. Veri Formatları (Data Formats): Çoğu modern RESTful API, hafifliği ve okunabilirliği nedeniyle JSON'u tercih eder. XML de kullanılabilir ancak daha az yaygındır. Medya tipini `Content-Type` başlığı ile belirtmeyi unutmayın (örn: `application/json`).[/li]
  [li]8. Filtreleme, Sıralama, Sayfalama (Filtering, Sorting, Pagination): Büyük veri kümeleriyle çalışırken bu özellikler olmazsa olmazdır. Sorgu parametreleri (query parameters) aracılığıyla uygulanır.
  
  Kod:

  GET /urunler?kategori=elektronik&sirala=fiyat_desc&limit=10&offset=20

  [/li]
  [li]9. Güvenlik (HTTPS): Tüm API iletişimleri için HTTPS kullanmak zorunludur. Bu, verilerin şifrelenmesini ve istemci ile sunucu arasında güvenli bir bağlantı kurulmasını sağlar.[/li]
  [li]10. Dokümantasyon: İyi bir API'nin olmazsa olmazı kapsamlı ve güncel dokümantasyondur. Swagger/OpenAPI gibi araçlar, API'nizi açıklamanıza ve test etmenize yardımcı olur.
  https://swagger.io/specification/
  [/li]

HATEOAS (Hypermedia As The Engine Of Application State), REST'in en az anlaşılan ama en güçlü prensiplerinden biridir. Bir API'nin gerçek bir RESTful API olabilmesi için HATEOAS prensibine uyması gerekir.

Genişletmek için tıkla ...

GET /siparisler/123

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "urunAdi": "Akıllı Telefon X",
  "adet": 1,
  "toplamFiyat": 5999.99,
  "durum": "Hazırlanıyor",
  "_links": [
    {
      "rel": "self",
      "href": "/siparisler/123",
      "method": "GET"
    },
    {
      "rel": "update-order",
      "href": "/siparisler/123",
      "method": "PUT"
    },
    {
      "rel": "cancel-order",
      "href": "/siparisler/123/iptal",
      "method": "POST"
    },
    {
      "rel": "customer",
      "href": "/musteriler/456",
      "method": "GET"
    }
  ]
}

• 
  [li]Boş (Null) Değerler: Bir alanın değeri yoksa, API yanıtında o alanı hiç göndermemek mi yoksa `null` olarak göndermek mi daha iyi? Genellikle hiç göndermemek daha temizdir, ancak bu API tasarım standardınıza bağlıdır.[/li]
  [li]Toplu İşlemler (Batch Operations): Bazen tek bir istekte birden fazla kaynak üzerinde işlem yapmak isteyebilirsiniz (örn. birden fazla ürünü silmek). Bu tür senaryolar için özel bir uç nokta (`/batch`) tasarlayabilir veya uygun bir metotla (`POST`) listeleri kabul edebilirsiniz.[/li]
  [li]Genişletilebilirlik (Extensibility): API'nizin gelecekteki ihtiyaçlara kolayca uyum sağlayabilmesi için genişletilebilir olması önemlidir. Yeni alanlar eklemek veya mevcut alanları değiştirmek mümkün olmalıdır.[/li]
  [li]Kaynaklar Arası İlişkiler: Bir kaynağın diğer kaynaklarla ilişkisi nasıl ifade edilmeli? URI'lar (`/users/{userId}/orders`) veya ilişkisel bağlantılar (`_links` objesi içinde) aracılığıyla bu ilişkiler kurulabilir.[/li]
  [li]Request Payloads: Özellikle POST ve PUT isteklerinde gönderilen veri gövdesinin (payload) yapısı da tutarlı olmalıdır. Genellikle JSON formatında gönderilir ve API dokümantasyonunda şeması belirtilmelidir.
  
  Kod:

  POST /urunler
  Content-Type: application/json
  
  {
    "ad": "Yeni Akıllı Telefon",
    "aciklama": "Yüksek performanslı, yeni nesil akıllı telefon.",
    "fiyat": 7499.99,
    "stokAdedi": 150,
    "kategoriId": 5
  }

  [/li]