REST API Tasarım Rehberi

Merhaba. Bu yazıda REST’in özelliklerinden ve iyi bir REST API tasarımı için dikkat etmemiz gereken ayrıntılardan bahsedeceğim. Kavram kargaşası olmaması için anahtar kelimeleri İngilizce karşılıklarıyla yazacağım.

REST API Tasarım Rehberi
├── REST Nedir?
└── REST'in Özellikleri
    ├── Stateless
    ├── Uniform Interface
    ├── Cacheable
    ├── Client-Server
    ├── Layered System
    └── Code On Demand
└── URI
    ├── URI Hiyerarşisi
    ├── URI'da Karakter Kullanımı
    ├── Resource Modelleri
    ├── URI Path İsimlendirme Kuralları
    └── URI'da Query Kullanımı
└── REST'te HTTP Metotlarının Kullanımı
    ├── Safe ve Idempotent Metotlar     
    └── Response Code’lar

REST Nedir?

Önce basit bir tanım yapıp örnekler ışığında bu tanımı genişletelim. REST(REpresentational State Transfer), web uygulamalarında temsili state transferi için kullandığımız bir mimaridir. Tabii cümle bu haliyle pek bir şey ifade etmiyor. Bir örnekle beraber tanımımıza yeni kavramlar ekleyelim.

Bunu bir örnek üzerinden anlatacağım. Bir alışveriş sitesinde “Dell XPS” anahtar kelimeleriyle bir arama yaptınız ve karşınıza aradığınız kelimelere ilişkin ürünler ve her ürüne ait kapak fotoğrafı, başlık, fiyat gibi bilgiler çıktı. Bu bilgiler client’ın, yani sizin, server’a yaptığı istek sonucu edindiği bilgiler. Örneğimizdeki client-server iletişiminde Dell XPS dizüstü bilgisayarlar resource oluyor. Yani kullanıcıların göreceği, güncelleyeceği, sileceği kadar önemli olduğunu düşündüğünüz ve bu sebeple isim verdiğiniz kaynaklar (products). Ürünlerdeki fiyat bilgisi dönem dönem değişebilen bir değer. Yani ürün resource’unun state’i sabit değil. Fakat bize bu resource’un en güncel hali gelir. State yalnızca bununla sınırlı değildir. Örneğin Dell XPS 13 9380 resource’unun stok bilgisi de olabilir fakat bir kullanıcı olarak bizim bunu görmeye yetkimiz yoktur. Yalnızca görmeye yetkili olduğumuz bilgileri içeren transfer de bu resource’un bir state’idir. Dell XPS 13 9380 başlıklı ürünün sayfasına gittiğimizde bizi o ürüne ait daha ayrıntılı bir sayfa karşılar. Teknik özellikler, fotoğraflar, taksit seçenekleri gibi birçok bilgiyi görürüz. Peki bu bilgiler bize hangi formatta geliyor? Ürünün ilgili sayfasına gittiğimizde bir REST isteği ile resource’un state’ini istiyoruz ve bize cevap olarak bir JSON dosyası geliyor. Aşağıdaki JSON dosyası bir örnek olabilir:

{
   "id": 1,
   "title": "Dell XPS 13 9380 Intel Core i7 8565U 16GB 512GB SSD Windows 10 Pro 13.3 HD Taşınabilir Bilgisayar UT56WP165N",
   "brand": "Dell",
   "model": "XPS 13 9380",
   "images": [
      "http://placekitten.com/g/200/300",
      "http://placekitten.com/g/200/300",
      "http://placekitten.com/g/200/300"
   ]
}

Bu JSON dosyası da resource’un bir representation’ı. JSON olması zorunlu değil. XML veya başka bir şey de olabilir.

Basit bir REST iletişiminin üç temel aktörü

Yukarıdaki kavramlar ışığında tanımı tekrar düşündüğümüzde bize daha çok şey ifade ediyor: “…web uygulamalarında temsili state transferi için kullandığımız bir mimaridir.”

REST’in Özellikleri

REST mimarisinin kısıtlarına baktığımızda karşımıza altı madde çıkar:

1. Stateless
2. Uniform Interface
3. Cacheable
4. Client-Server
5. Layered System
6. Code on Demand

Bu bölümde yukarıdaki kısıtların neler olduğunu ve bunlara neden ihtiyaç duyduğumuzu anlatacağım.

Stateless

REST’in stateless olması server’ın client hakkında session gibi bilgileri tutmaması demektir. Bu gibi bilgileri yalnızca client tutar. Dolayısıyla server, istek yapan client’ın daha önce kaç istek yaptığı veya hangi istekleri yaptığı gibi bilgileri tutmaz. Client ise yaptığı istekte server’ın ihtiyaç duyduğu tüm bilgileri verir.

REST stateless olduğu için monitoring aracı kullanıyorsanız ihtiyaç duyduğunuz tüm bilgiler ilgili isteğin içinde olacaktır. Geçmişe yönelik bir tarama yapmanız gerekmez (visibility). Her reguest arasında bir kayıt tutmak zorunluluğu olmadığı için kaynak tüketimi azdır ve mimarinin uygulanması daha kolaydır (scalibility).

Fakat aynı zamanda server, client’a ilişkin veri tutmadığı için client’ın her istekte bazı bilgileri göndermesi maliyeti artırır. Bu da stateless oluşunun dezavantajı olarak sayılabilir.

Uniform Interface

Bu kısıt, client ve server arasındaki iletişim için belirlenmiş dört prensiple sağlanır:

• Her istekte resource’ları tanımlayan bir resource identifier kullanılır. Bunu sağlamak için URI standartları kullanılır.
• Bildiğimiz üzere client, yaptığı istek sonucunda server’dan bir representation alır. Resource dediğimiz şey veritabanında bir row olabilir. Representation ise bunun temsilidir. Uniform interface kısıtına göre client sahip olduğu response ile o resource’u silecek, değiştirecek kadar bilgiye sahip olmalıdır.
• İstekler kendilerini tanımlayıcı bilgileri barındırmalıdır. Örneğin gelen representation’ın hangi formatta geldiğini söyleyip client’ı hangi parser’ı kullanacağı yönünde bilgilendirir. (bkz. mime types)
• Client’lar istek yaparken dört farklı yolla bilgi aktarır: İstek body’si, query-string parametreleri, header’lar ve URI. Server ise üç farklı yolla bunu yapar: response içeriği, response code ve response header.

Cacheable

Server, gönderdiği response’larda resource’un cacheable veya uncacheable olduğunu da söyler. Böylece client gönderilen bilgilere göre bir cache mekanizması oluşturabilir.

Client-Server

Yazılım tasarımında aşina olduğumuz bir kavram olan seperation of concerns prensibi REST tasarımında da uygulanır. Bu kısıta göre client, server’ın sorumluluğunda olan depolama işlemleri gibi şeylerle ilgilenmez. Aynı şekilde server da client’ın sorumluluğu olan user state gibi konularla ilgilenmez. Böylece server ve client iki farklı aktör olarak çalışır. Aralarındaki iletişim de client tarafından başlatılır. Server yalnızca client’tan gelen istekleri bekler. Bunun sonucunda client ve server birbirinden bağımsız olarak geliştirilir, server tarafında geliştirme basit ve ölçeklenebilirlik yüksek olur ve client tarafında ise kodun taşınabilirliği yüksek olur.

Layered System

Client-Server mimarisinden bahsederken kastımız her zaman bir client’ın doğrudan bir server’a istek göndermesi ve ondan doğrudan cevap alması şeklinde değildir. Aralarda güvenlik katmanı, cache katmanı gibi katmanlar olabilir. Böyle bir sistemde aralardaki katmanlar request ve response’a etki etmemeli. Her katman yalnızca iletişime geçtiği katmanları bilmeli.

Code On Demand

Zorunlu olmayan tek kısıt code on demand’dir. Code on demand kısıtı server’ın client’a belli durumlarda executable script’ler ve applet’ler gönderebilmesini kapsar.

URI

REST’te representation’ını sunduğumuz verilerin temel kaynağının resource olduğundan bahsetmiştim. REST API tasarımında resource’ları adreslemek için URI’ları kullanırız. Ayrıntılı RFC dokümanını bu adresten bulabileceğiniz URI (Uniform Resource Identifier), client’ın ulaşmak istediği representation’ı bir dizi kurala uyarak uniform bir linkle gösterir. URI hakkında şimdilik bu kadar bilgi yeterli. Şimdi REST API’larda URI tasarımının nasıl olması gerektiğini inceleyelim.

URI Hiyerarşisi

API tasarımımızda client, tüm resource’lara bir hiyerarşi ile ulaşmalı. Bu hiyerarşiyi sağlamak için forward slash(/) kullanıyoruz. Aşağıda bazı hiyerarşi örnekleri var:

• https://ornek-api.com/api/v1/users/123456/media/audio
• https://api.ornek.com/posts/3456/comments/1
• https://api.wubbalubbadubdub.com/v1/users

https://api.deneme.com/users/123/friends/456 URI’ı 123 ID’li user’ın 456 ID’li arkadaşını işaret eder. Bu URI tasarımında aşağıdaki URI’ların hepsi bir resource’u göstermeli.

https://api.deneme.com/users/123/friends/456
https://api.deneme.com/users/123/friends
https://api.deneme.com/users/123
https://api.deneme.com/users

URI’da Karakter Kullanımı

• URI okunurluğunu artırmak için birden fazla kelimenin bir araya geldiği yerlerde araya tire(-) koyulur.

https://api.ornek.com/v1/users/234234/unread-messages/1

• URI’larda alt tire(_) kullanılmaz. Kullanmanızı engelleyecek bir mekanizma yoktur fakat best practice olarak kabul edilen alışkanlık kullanmamak yönündedir. Alt tire kullanmaya ihtiyacınız olduğu yerde tire kullanmak daha doğru bir tercihtir.
• Her zaman küçük harfler kullanın. RFC 3986 6.2.2.1'e göre URI’da host ve scheme dışındaki parçalar case-sensitive’dir. Dolayısıyla aşağıdaki iki URI iki farklı şeyi ifade eder.

https://api.ornek.com/users/123/docs/456
https://api.ornek.com/users/123/Docs/456

Yukarıdaki URI’larda scheme https ve host ise api.ornek.com ‘dur.

• URI’da dosya uzantısı olmaz. Dosya uzantısı yerine Content-Type header’ı ile dosyanın formatını iletmek daha doğru bir yaklaşımdır.

h̶t̶t̶p̶s̶:̶/̶/̶a̶p̶i̶.̶d̶e̶n̶e̶m̶e̶.̶c̶o̶m̶/̶u̶s̶e̶r̶s̶/̶1̶2̶3̶/̶d̶o̶c̶s̶/̶c̶v̶.̶p̶d̶f̶
https://api.deneme.com/users/123/docs/cv

URI’ın Bölümleri

Resource Modelleri

REST API’larımızda resource’ları modellemek için 4 farklı model kullanırız. Bu modeller design pattern’larda olduğu gibi ortak bir dili konuşmamızı ve daha temiz bir tasarım yapmamızı sağlar. Şimdi bu modelleri inceleyelim.

• Document

Diğer 3 modelin temel modeli olarak kabul edebileceğimiz document, yabancı olduğumuz bir konsept değildir. Bir sınıfa ait instance veya veritabanındaki bir kayıt document olabilir. Değerlerin ve diğer gerekli resource’lara ilişkin linklerin bulunduğu alanlara sahiptir. Aşağıdaki JSON representation basit bir document’a aittir.

{
   "name": "Damien Rice",
   "birthDate": "12/7/1973",
   "albums": [
          "O", 
          "9",
          "My Favourite Faded Fantasy" 
   ],
   "officialWebsite": "https://www.damienrice.com/"
}

Aşağıdaki linkler ise örnek document URI’larıdır:

https://api.ornek.com/v1/artists/54352
https://api.ornek.com/v1/artists/54352/albums/2
https://api.ornek.com/v1/cities/ankara
https://api.ornek.com/v1/cities/ankara/districts/yenimahalle

• Collection

Collection’lar server tarafından yönetilen document resource listeleridir. URI isimlendirmesi yaparken tüm collection’lar çoğul yazılmalıdır. Aşağıdakiler örnek collection URI’larıdır:

https://api.ornek.com/v1/artists
https://api.ornek.com/v1/artists/54352/albums
https://api.ornek.com/v1/cities
https://api.ornek.com/v1/cities/ankara/districts

Client’lar yeni resource’lar ekleyebilir fakat ekleyip eklememe kararı server’a aittir. Bunun ayrıntılarına ileride değineceğim.

• Store

Store, collection’dan farklı olarak client tarafından yönetilen resource modelidir. Güncelleme yapmaya, silmeye izin verir fakat store’lar ile yeni URI yaratılamaz.

https://ornek.com/api/v1/playlists/123/songs
https://ornek.com/api/v1/users/123/carts

• Controller

API’ımızda standart metotların (GET, POST, PUT, DELETE…) ihtiyacımızı karşılamadığı durumlarda controller’lar devreye girer. Controller’lar yazılım dillerindeki fonksiyonlar gibi parametreler alır, output değerler verir. Application-spesific olan controller’lar, URI hiyerarşisinde en sonda bulunur. Child resource’ları olmaz.

https://api.ornek.com/v1/alerts/4234/resend

URI Path İsimlendirme Kuralları

• Document’lar tekil isimlerle ifade edilir.

https://ornek.com/api/v1/countries/turkey
https://ornek.com/api/v1/countries/turkey/cities/izmir

• Collection’lar çoğul isimlerle ifade edilir.

https://ornek.com/api/v1/universities/gazi/faculties
https://ornek.com/api/v1/departments/it/employees

• Store’lar çoğul isimlerle ifade edilir.

https://ornek.com/api/v1/clients/audreyhepburn/accounts
https://ornek.com/api/v1/brands/honda/cars

• Controller’lar fiilerle ifade edilir.

https://ornek.com/api/v1/apps/calculator/run-tests
https://ornek.com/api/v1/tutors/richardstallman/register

• Controller’lar isimlendirilirken HTTP metodu metodu olarak karşılığı bulunan CRUD işlemlerinin isimleri kullanılmaz.

✗ h̶t̶t̶p̶s̶:̶/̶/̶a̶p̶i̶.̶o̶r̶n̶e̶k̶.̶c̶o̶m̶/̶v̶1̶/̶u̶s̶e̶r̶s̶/̶2̶3̶/̶d̶e̶l̶e̶t̶e̶-̶u̶s̶e̶r̶
✓ DELETE https://api.ornek.com/v1/users/23

URI’da Query Kullanımı

RFC 3986 3.4'te belirtildiği üzere query’ler hiyerarşik olmayan verileri adreslemek için kullanılır. Eğer kullandığımız veri hassas bir veri değilse, hiyerarşik bir konumu yoksa ve default header’larda bir karşılığı yoksa query kullanmak iyi bir tercih olabilir. Buna örnek olarak pagination ve filtering parametrelerini verebiliriz. Query’lerin yazımında URI’ın son segmentinden sonra soru işareti (?) eklenir ve ardından gelen değişkenler ampersand(&) işareti ile ayrılır.

https://ornek.com/api/v1/categories/1/posts?page=4
https://ornek.com/api/v1/categories/1/posts?orderby=desc&name=bob

REST’te HTTP Metotlarının Kullanımı

HTTP protokolünün standartları RFC 2616'da yazmaktadır. Bu bölümde büyük oranda bu dokümanı kullanacağım. Çünkü REST, HTTP protokolünün tüm gerekliliklerini karşılar. Şimdi REST’te HTTP metotlarının kullanımıyla alakalı kurallara geçelim.

• GET

GET metodu URI’da belirtilen resource’u getirmek için kullanılır. Bu istekte body olmaz. Yalnızca header olur.

Öğrenmek ve denemek maksadıyla ücretsiz API sunan bir siteye cURL ile bir GET isteği gönderelim.(Postman, Insomnia gibi araçlarla da yapabilirsiniz.)

curl -XGET 'https://jsonplaceholder.typicode.com/todos/1'

Header veya body eklemeden gönderdiğimiz isteğe cevap olarak aşağıdaki JSON representation’ı alıyoruz.

{
  "userId": 1,
  "id": 1,
  "title": "delectus aut autem",
  "completed": false
}

• HEAD

HEAD metodunun GET metodundan tek farkı response’ta body göndermemesidir. Bu isteği, response’ta gönderilecek olan header’lar için yaparız. Örneğin bir resource’un belirtilen URI’da olup olmadığını kontrol etmek için veya resource’un en son ne zaman değiştirildiğini görmek için kullanılabilir (Last-Modified).

Az önce GET metodu ile istek gönderdiğimiz adrese şimdi de HEAD ile istek gönderelim:

curl --head 'https://jsonplaceholder.typicode.com/todos/1'

HEAD metodu ile istek gönderdiğimiz için gelen response’ta body olmayacak. Fakat header’ları görebiliriz.

HTTP/2 200 
date: Tue, 13 Aug 2019 14:00:29 GMT
content-type: application/json; charset=utf-8
content-length: 83
set-cookie: __cfduid=d1302ca481dbaeb87942f86fe7c4d7c3f1565704829; expires=Wed, 12-Aug-20 14:00:29 GMT; path=/; domain=.typicode.com; HttpOnly
x-powered-by: Express
vary: Origin, Accept-Encoding
access-control-allow-credentials: true
cache-control: public, max-age=14400
pragma: no-cache
expires: Tue, 13 Aug 2019 18:00:29 GMT
x-content-type-options: nosniff
etag: W/"53-hfEnumeNh6YirfjyjaujcOPPT+s"
via: 1.1 vegur
cf-cache-status: HIT
age: 3139
accept-ranges: bytes
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 505b372e3d82d6c1-FRA

• POST

POST metodunu istek gönderdiğimiz server’da yeni bir resource oluşturmak için, controller resource’ları çalıştırmak için ve form input’larını göndermek için kullanırız. Tüm bu işlemler için veri göndereceğimiz için POST metodunu kullanırken body de göndeririz.

Yine aynı sitede yeni bir post oluşturmak için POST isteği ile title ve body değişkenlerini gönderiyoruz.

curl -X POST https://jsonplaceholder.typicode.com/posts \
  -d '{
          "title": "Foo",
          "body": "Bar"
      }'

Cevap olarak ise oluşturduğumuz post’un bilgilerini alıyoruz.

{
    "title": "Foo",
    "body": "Bar",
    "id": 101
}

• PUT

PUT metodu, POST metoduna benzeyen bir kullanım alanına sahiptir. Body ile bir resource gönderilir ve eğer URI varolan bir resource’u gösteriyorsa o resource güncellenir.

• DELETE

Adından da anlaşılacağı üzere URI’da belirtilen resource’u silmek için gönderilen istektir. Yalnızca ilgili resource’un silinmesi ve bir daha hiçbir şekilde ulaşılmaması için kullanılır. Eğer soft-delete yapılacaksa bunun için application-spesific bir controller tanımlanır.

• OPTIONS

İstek gönderdiğimiz URI’ın hangi metotları desteklediğini öğrenmek için kullanırız. Bu bilgi bize header’da allow ile verilir.

• PATCH

PATCH metodu PUT’a benzer fakat resource’da kısmı güncelleme yapılacaksa kullanılır. Örneğin bir blog postunun yalnızca başlığı güncellenecekse PATCH metodu ile body’de başlığı göndermek maliyet açısından daha doğru bir tercih olur.

Safe ve Idempotent Metotlar

Eğer bir metot mantıksal olarak read-only çalışıyorsa ve bu metotla yaptığımız istekler sunucuda herhangi bir zarara ve değişikliğe sebep olmuyorsa safe metot deriz. Yaptığımız istekler sonucunda sunucuda bazı loglamalar yapılıyor olabilir, bu da sunucuda bazı değişikliklere sebep oluyor olabilir. Fakat burada önemli olan client’ın bu metot ile ne talep ettiğidir. Eğer GET kullanarak bir resource talep ediyorsa read-only bir işlem yapıyordur. GET, HEAD, OPTIONS ve TRACE metotları safe olarak kabul edilir. Aslında POST metodu ile read-only bir işlem yapmanızı veya GET ile un-safe bir işlem yapmanızı engelleyen bir mekanizma yoktur fakat RFC’yi temel alarak geliştirme yaptığımız için bu kuralların dışına çıkmamak gerekir.

Eğer bir metotla bir veya daha fazla işlem yaptığınızda hep aynı sonucu almayı bekliyorsanız bu metot idempotent’tir. RFC’ye göre PUT, DELETE metotları ve safe metotlar idempotent’tir. Örneğin PUT metotu ile bir kullanıcının mail adresini güncellemek istediğimizde her seferinde aynı sonucu almayı bekleriz. Fakat POST isteği ile sunucuda yeni resource oluştururken eğer isteği birden fazla gönderirsek her seferinde yeni bir resource oluşur.

Bu tanımlamaların ne işimize yarayacağını da bir örnekle açıklamak istiyorum. Kullandığımız browserlar RFC’ye göre hazırlanmıştır. Bu sebeple bazı internet sitelerinde form gönderdikten sonra sayfayı refresh’lediğinizde bir uyarı almışsınızdır. Bunun sebebi, POST isteğinin idempotent olmadığını bilen browser’ın, sunucuda birden fazla resource oluşturmanızı engellemek istemesidir. Fakat form GET ile gönderilmiş olsaydı idempotent olduğu için browser, kullanıcıları uyarmayacaktı. Konudan bağımsız olarak küçük bir hatırlatma yapayım, bu uyarıyı her zaman almazsanız. Çünkü formu gönderdikten sonra birçok web sitesi sizi başka bir sayfaya yönlendirir.

Response Code’lar

RFC 2616'da belirlenmiş olan status code’lar gönderilen isteğin durumunu client’a standart bir şekilde ifade eder. Eğer bir hata varsa hatayı, gönderilen istek başarılı bir şekilde işlem gördüyse ona ilişkin durumu aktarır. Status code’lar 5 kategoriye ayrılmıştır.

• 1xx Bilgi
• 2xx Başarılı
• 3xx Yönlendirme
• 4xx Client Hatası
• 5xx Server Hatası

Şimdi bu kategorilerde en çok kullanılan status code’ları inceleyelim.

• 200 OK

Gönderilen isteğin başarılı bir şekilde görevini yerine getirdiğini ifade eder. Body’de döndürülecek olan şeyler isteğe göre değişir. Eğer GET isteği gönderildiyse istenen resource body’de, HEAD isteği gönderildiyse istenen bilgiler header’da, POST isteği gönderildiyse yapılan işlemin sonucu gönderilir.

• 201 Created

Client’ın isteğiyle bir resource yaratıldıysa 201 kodu döndürülür. Burada önemli olan iki nokta vardır. Resource yaratılmadan önce 201 döndürülmez. Eğer bu işlem uzun sürecekse 202 Accepted kodu döndürülür.

• 202 Accepted

Client’ın gönderdiği isteğin yerine getirilmesi zaman alacaksa ve asenkron olara devam edecekse 202 döndürülür. Fakat bu kod işlem yerine getirildiğinde başarılı olacağını garanti etmez. Hata da verebilir.

Controller’lar 202 kodunu kullanabilir fakat diğer resource’ların kullanması doğru değildir.

• 204 No Content

Client’ın gönderdiği isteğe karşılık olarak herhangi bir body gönderilmediği durumlarda server’ın kasıtlı olarak body alanını boş bıraktığını belirtmek için kullanılır.

• 301 Moved Permanently

Client’ın istek gönderdiği URI’ın artık kullanılmadığını ve başka bir adreste hizmet verdiğini belirtir. Response’ta bu kodla beraber header’da Location alanında yeni URI gönderilmelidir.

• 304 Not Modified

Bu kod 204'e benzer. Body’siz gönderilir. Client’ın resource’un zaten en güncel haline sahip olduğunu belirtir.

• 400 Bad Request

Genel 4xx kodudur. Diğer kodların ihtiyacımızı karşılamadığı durumlarda 400 kullanılır.

• 401 Unauthorized

Korumalı bir resource’a gerekli authorization sağlanmadan erişilmeye çalışıldığını ifade eder.

• 403 Forbidden

Bu kod 401'le karıştırılır ama aralarındaki fark şudur: Authorization bilgileri hiç gönderilmediyse veya yanlış gönderildiyse 401, eğer authorization sağlanan kullanıcının istenen kaynağa erişim yetkisi yoksa 403 döndürülür.

• 404 Not Found

Client’ın istediği resource’un bulunamadığını ifade eder.

• 405 Method Not Allowed

İstek yapılan URI’ın ilgili metodu desteklemediğini belirtir. Örneğin yalnızca okuma izni verilmiş bir resource POST isteği gönderilirse 405 döner.

• 406 Not Acceptable

Server’ın, client’ın gönderdiği istekte header’da Accept alanında yazdığı medya tiplerinden herhangi bir formatta çıktı veremediğini belirtir. Örneğin isteğin Accept alanında yalnızca application/json varsa ve server JSON tipinde çıktı veremiyorsa 406 döner.

• 409 Conflict

Client’ın gönderdiği istekle server’daki resource’u olmaması gereken bir duruma getirmeye çalıştığını ifade eder. Örneğin client nullable olmayan bir alanı null yapmaya çalışırsa 409 döner.

• 415 Unsupported Media Type

Server’a, desteklemediği tipte bir resource gönderildiğinde 415 döner.

• 500 Internal Server Error

Aynı 400 gibi genel 5xx kodudur. Server’ın hatası yüzünden istek yerine getirilemiyorsa kullanılır.

Yararlandığım Kaynaklar

• REST API Design Rulebook by Mark Masse
• https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
• https://www.ietf.org/rfc/rfc2616.txt
• https://tools.ietf.org/html/rfc3986
• https://blogs.dropbox.com/developers/2015/03/limitations-of-the-get-method-in-http/