API geli\u015ftirme s\u00fcrecinde, istemci ile sunucu aras\u0131ndaki ileti\u015fimin temelini olu\u015fturan HTTP durum kodlar\u0131, sistemlerinizin sa\u011fl\u0131kl\u0131 \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flaman\u0131n yan\u0131 s\u0131ra hata ay\u0131klama ve kullan\u0131c\u0131 deneyimi a\u00e7\u0131s\u0131ndan kritik bir rol oynar. Bu kodlar, her bir iste\u011fin sonucunu standartla\u015ft\u0131r\u0131lm\u0131\u015f bir \u015fekilde ileterek, API’lerinizin hem anla\u015f\u0131l\u0131r hem de bak\u0131m\u0131 kolay olmas\u0131n\u0131 sa\u011flar.<\/p>\n
API’ler, modern yaz\u0131l\u0131m mimarilerinin bel kemi\u011fini olu\u015fturur ve uygulamalar aras\u0131 veri al\u0131\u015fveri\u015fini m\u00fcmk\u00fcn k\u0131lar. Bu al\u0131\u015fveri\u015fin temelinde ise HTTP (Hypertext Transfer Protocol) yatar. HTTP, istemcilerin (taray\u0131c\u0131lar, mobil uygulamalar veya di\u011fer servisler) sunuculara (API’niz) istek g\u00f6ndermesi ve sunucular\u0131n bu isteklere yan\u0131t vermesi \u00fczerine kurulu bir protokold\u00fcr. \u0130\u015fte bu yan\u0131tlar\u0131n \u00f6nemli bir par\u00e7as\u0131 da HTTP durum kodlar\u0131d\u0131r. Peki, bu \u00fc\u00e7 haneli say\u0131lar tam olarak ne anlama gelir ve API geli\u015ftirme s\u00fcrecinde neden bu kadar kilit bir role sahiptir?<\/p>\n
Her bir HTTP durum kodu, sunucunun bir iste\u011fi ba\u015far\u0131yla i\u015fleyip i\u015fleyemedi\u011fini veya i\u015flem s\u0131ras\u0131nda ne t\u00fcr bir sorunla kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131 g\u00f6steren standart bir mesajd\u0131r. Bu kodlar, genellikle \u00fc\u00e7 basamakl\u0131 say\u0131lardan olu\u015fur ve ilk basamak, yan\u0131t\u0131n genel kategorisini belirtir. Bu kategoriler, 1xx’den 5xx’e kadar uzan\u0131r ve her biri farkl\u0131 bir anlama gelir:<\/p>\n
* 1xx (Bilgilendirici Yan\u0131tlar):<\/strong> \u0130stek al\u0131nd\u0131 ve i\u015flem devam ediyor. Nadiren do\u011frudan API yan\u0131tlar\u0131nda kullan\u0131l\u0131r. Bu kodlar, API geli\u015ftiricileri i\u00e7in sadece hata ay\u0131klama arac\u0131 olmaktan \u00f6te, ayn\u0131 zamanda iyi bir API tasar\u0131m\u0131n\u0131n ve kullan\u0131c\u0131 deneyiminin temelini olu\u015fturur. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n mobil uygulamas\u0131 sunucuya bir veri g\u00f6nderme iste\u011fi yapt\u0131\u011f\u0131nda, 201 Created kodu, verinin ba\u015far\u0131yla kaydedildi\u011fini bildirirken, 400 Bad Request kodu, g\u00f6nderilen veride bir hata oldu\u011funu ve istemcinin iste\u011fi d\u00fczeltmesi gerekti\u011fini belirtir. Bu sayede, istemci taraf\u0131 ald\u0131\u011f\u0131 yan\u0131t\u0131 kolayca anlayabilir ve buna g\u00f6re aksiyon alabilir. Bu durum, \u00f6zellikle karma\u015f\u0131k ve da\u011f\u0131t\u0131k sistemlerde, farkl\u0131 servislerin birbiriyle tutarl\u0131 bir \u015fekilde ileti\u015fim kurabilmesi i\u00e7in vazge\u00e7ilmezdir.<\/p>\n Ayr\u0131ca, durum kodlar\u0131n\u0131n do\u011fru kullan\u0131m\u0131, API’lerinizin daha g\u00fcvenilir ve bak\u0131m\u0131 daha kolay olmas\u0131n\u0131 sa\u011flar. Geli\u015ftiriciler, bir hata kodu g\u00f6rd\u00fcklerinde, sorunun kayna\u011f\u0131n\u0131 h\u0131zla tespit edebilirler. Sunucu hatalar\u0131 (5xx) genellikle altyap\u0131 veya kod sorunlar\u0131na i\u015faret ederken, istemci hatalar\u0131 (4xx) genellikle API kullan\u0131m\u0131nda veya girdi verilerinde bir sorun oldu\u011funu g\u00f6sterir. B\u00f6ylece, sorunlar\u0131n kategorize edilmesi ve \u00e7\u00f6z\u00fcme y\u00f6nelik ad\u0131mlar\u0131n at\u0131lmas\u0131 \u00e7ok daha verimli hale gelir.<\/p>\n Dolay\u0131s\u0131yla, API geli\u015ftirme yolculu\u011funuzda, HTTP durum kodlar\u0131na hakim olmak, sadece “i\u015fleyen” bir API de\u011fil, ayn\u0131 zamanda “sa\u011flam”, “anla\u015f\u0131l\u0131r” ve “bak\u0131m\u0131 kolay” bir API olu\u015fturman\u0131z i\u00e7in temel bir ad\u0131md\u0131r. Bu kodlar, API’nizin kullan\u0131c\u0131lar\u0131yla ve di\u011fer servislerle kurdu\u011fu sessiz ama etkili bir ileti\u015fim dilidir. Bu dili do\u011fru kullanmak, geli\u015ftirdi\u011finiz sistemlerin genel kalitesini do\u011frudan etkileyecektir.<\/p>\n API geli\u015ftirme s\u00fcrecinde en \u00e7ok g\u00f6rmeyi arzulad\u0131\u011f\u0131m\u0131z yan\u0131tlar \u015f\u00fcphesiz 2xx s\u0131n\u0131f\u0131na ait olanlard\u0131r. Bu durum kodlar\u0131, bir istemcinin g\u00f6nderdi\u011fi iste\u011fin sunucu taraf\u0131ndan ba\u015far\u0131yla al\u0131nd\u0131\u011f\u0131n\u0131, anla\u015f\u0131ld\u0131\u011f\u0131n\u0131 ve amac\u0131na ula\u015ft\u0131\u011f\u0131n\u0131 g\u00f6sterir. Do\u011fru 2xx kodu se\u00e7imi, API’nizin davran\u0131\u015f\u0131n\u0131 a\u00e7\u0131k\u00e7a belirtir ve istemcilerin sonraki ad\u0131mlar\u0131 do\u011fru bir \u015fekilde atmas\u0131na yard\u0131mc\u0131 olur. Gelin, en s\u0131k kullan\u0131lan ba\u015far\u0131l\u0131 yan\u0131t kodlar\u0131n\u0131 ve kullan\u0131m senaryolar\u0131n\u0131 inceleyelim.<\/p>\n 200 OK, HTTP’nin en bilinen ve en yayg\u0131n ba\u015far\u0131l\u0131 yan\u0131t\u0131d\u0131r. Bir GET, PUT, POST veya DELETE iste\u011finin ba\u015far\u0131yla tamamland\u0131\u011f\u0131n\u0131 ve beklenen bir yan\u0131t g\u00f6vdesinin (body) d\u00f6nd\u00fcr\u00fcld\u00fc\u011f\u00fcn\u00fc belirtir. \u00d6zellikle bir kaynaktan bilgi almak (GET) veya bir kayna\u011f\u0131 g\u00fcncellemek (PUT\/PATCH) gibi i\u015flemlerden sonra bu kodu s\u0131k\u00e7a g\u00f6r\u00fcr\u00fcz.<\/p>\n Kullan\u0131m Senaryosu:<\/strong> Bir e-ticaret uygulamas\u0131nda, kullan\u0131c\u0131lar\u0131n sepetlerindeki \u00fcr\u00fcnleri listelemek i\u00e7in bir API iste\u011fi g\u00f6nderdi\u011fini d\u00fc\u015f\u00fcnelim.<\/p>\n <\/code><\/p>\n Bu \u00f6rnekte, 201 Created, bir POST iste\u011finin ba\u015far\u0131yla sonu\u00e7land\u0131\u011f\u0131n\u0131 ve sunucuda yeni bir kaynak olu\u015fturuldu\u011funu belirtir. Bu yan\u0131t, genellikle olu\u015fturulan kayna\u011f\u0131n URL'sini i\u00e7eren bir Vaka Analizi: E-ticaret Uygulamas\u0131nda Sipari\u015f Olu\u015fturma<\/strong><\/p>\n Bir kullan\u0131c\u0131n\u0131n, sepetindeki \u00fcr\u00fcnleri kullanarak yeni bir sipari\u015f olu\u015fturdu\u011funu varsayal\u0131m. \u0130stemci, API'ye bir POST iste\u011fi g\u00f6nderir:<\/p>\n <\/code><\/p>\n Bu durumda, sunucu ba\u015far\u0131l\u0131 bir 201 yan\u0131t\u0131 d\u00f6nd\u00fcrerek hem sipari\u015fin ba\u015far\u0131yla kaydedildi\u011fini onaylar hem de yeni sipari\u015fin detaylar\u0131na nas\u0131l eri\u015filece\u011fini (genellikle 204 No Content, bir iste\u011fin ba\u015far\u0131yla i\u015flendi\u011fini ancak sunucunun yan\u0131t olarak herhangi bir i\u00e7erik d\u00f6nd\u00fcrmesine gerek olmad\u0131\u011f\u0131n\u0131 belirtir. \u00d6zellikle DELETE istekleri veya bir kayna\u011f\u0131n ba\u015far\u0131l\u0131 bir \u015fekilde g\u00fcncellendi\u011fi (ancak g\u00fcncelleme sonras\u0131 kayna\u011f\u0131n kendisinin d\u00f6nd\u00fcr\u00fclmesine gerek olmad\u0131\u011f\u0131) senaryolarda kullan\u0131l\u0131r. Bu, a\u011f trafi\u011fini azaltmaya yard\u0131mc\u0131 olur.<\/p>\n Kullan\u0131m Senaryosu:<\/strong> Bir kullan\u0131c\u0131n\u0131n blog g\u00f6nderisini sildi\u011fi bir API d\u00fc\u015f\u00fcnelim.<\/p>\n <\/code><\/p>\n Burada 204 yan\u0131t\u0131, g\u00f6nderinin ba\u015far\u0131yla silindi\u011fini ancak sunucunun silinen kayna\u011f\u0131n herhangi bir detay\u0131n\u0131 veya onay mesaj\u0131n\u0131 g\u00f6ndermeye gerek duymad\u0131\u011f\u0131n\u0131 g\u00f6sterir.<\/p>\n Ba\u015far\u0131l\u0131 yan\u0131t kodlar\u0131n\u0131n do\u011fru ve tutarl\u0131 kullan\u0131m\u0131, API'nizin tahmin edilebilirli\u011fini art\u0131r\u0131r ve hem API'yi t\u00fcketen geli\u015ftiricilerin hem de son kullan\u0131c\u0131lar\u0131n daha sorunsuz bir deneyim ya\u015famas\u0131n\u0131 sa\u011flar. Her ba\u015far\u0131l\u0131 i\u015flemin sonunda do\u011fru 2xx kodunu d\u00f6nd\u00fcrmek, API tasar\u0131m\u0131n\u0131n temel ta\u015flar\u0131ndan biridir.<\/p>\n HTTP durum kodlar\u0131n\u0131n 3xx s\u0131n\u0131f\u0131, istemcinin iste\u011fini tamamlamak i\u00e7in ek bir eylem ger\u00e7ekle\u015ftirmesi gerekti\u011fini belirtir. Bu genellikle, istenen kayna\u011f\u0131n farkl\u0131 bir URL'ye ta\u015f\u0131nd\u0131\u011f\u0131 veya iste\u011fin ba\u015fka bir kayna\u011fa y\u00f6nlendirilmesi gerekti\u011fi durumlarda ortaya \u00e7\u0131kar. Y\u00f6nlendirmeler, API s\u00fcr\u00fcm y\u00fckseltmeleri, kal\u0131c\u0131 URL de\u011fi\u015fiklikleri veya y\u00fck dengeleme gibi senaryolarda kritik bir rol oynar. Do\u011fru 3xx kodunun kullan\u0131lmas\u0131, hem istemci davran\u0131\u015f\u0131n\u0131 optimize eder hem de arama motoru optimizasyonu (SEO) a\u00e7\u0131s\u0131ndan \u00f6nem ta\u015f\u0131r.<\/p>\n 301 Moved Permanently, istenen kayna\u011f\u0131n kal\u0131c\u0131 olarak yeni bir URL'ye ta\u015f\u0131nd\u0131\u011f\u0131n\u0131 ve gelecekteki t\u00fcm isteklerin bu yeni URL'ye yap\u0131lmas\u0131 gerekti\u011fini belirtir. Bu yan\u0131t, Kullan\u0131m Senaryosu:<\/strong> Bir API'nin eski bir u\u00e7 noktas\u0131n\u0131 yeni bir yap\u0131ya ta\u015f\u0131d\u0131\u011f\u0131n\u0131z\u0131 d\u00fc\u015f\u00fcnelim. \u00d6rne\u011fin, <\/code><\/p>\n Bu durumda, eski u\u00e7 noktaya yap\u0131lan her istek, otomatik olarak yeni u\u00e7 noktaya y\u00f6nlendirilir. Bu, hem eski entegrasyonlar\u0131n k\u0131r\u0131lmamas\u0131n\u0131 sa\u011flar hem de istemcilere g\u00fcncel URL'yi bildirir. \u00d6zellikle halka a\u00e7\u0131k API'lerde veya web sitelerinde, SEO de\u011feri ta\u015f\u0131yan URL'lerin kal\u0131c\u0131 olarak ta\u015f\u0131nmas\u0131 gerekti\u011finde 301 kullan\u0131m\u0131 olmazsa olmazd\u0131r.<\/p>\n * 302 Found:<\/strong> \u0130stek tamamlanana kadar kayna\u011f\u0131n ge\u00e7ici olarak ba\u015fka bir adreste bulundu\u011funu belirtir. \u0130stemciler, gelecekteki istekler i\u00e7in orijinal URL'yi kullanmaya devam etmelidir. Bu, genellikle bir kayna\u011f\u0131n ge\u00e7ici olarak bak\u0131ma al\u0131nmas\u0131 veya sunucu taraf\u0131nda ge\u00e7ici bir y\u00f6nlendirme gerekti\u011finde kullan\u0131l\u0131r. Ancak, baz\u0131 eski istemciler 302'yi yanl\u0131\u015fl\u0131kla 303 gibi davranabilir, bu da POST istekleri sonras\u0131 GET y\u00f6nlendirmelerinde sorunlara yol a\u00e7abilir. Kullan\u0131m Senaryosu: Form G\u00f6nderimi Sonras\u0131 Onay Sayfas\u0131na Y\u00f6nlendirme<\/strong><\/p>\n Bir kullan\u0131c\u0131 bir form doldurup g\u00f6nderdi\u011finde, sunucu veriyi i\u015fledikten sonra kullan\u0131c\u0131y\u0131 bir onay sayfas\u0131na y\u00f6nlendirmek isteyebilir.<\/p>\n <\/code><\/p>\n Bu \u00f6rnekte, * 307 Temporary Redirect:<\/strong> 302'ye benzer \u015fekilde ge\u00e7ici bir y\u00f6nlendirmedir, ancak istemcinin orijinal iste\u011fin HTTP metodunu (GET, POST vb.) korumas\u0131n\u0131 garanti eder. Yani, bir POST iste\u011fi 307 yan\u0131t\u0131 al\u0131rsa, istemci yeni URL'ye de bir POST iste\u011fi g\u00f6nderir. 302'de ise istemci bazen POST'u GET'e \u00e7evirebilirdi. \u00d6nemli Not:<\/strong> 301\/302 genellikle taray\u0131c\u0131lar taraf\u0131ndan GET iste\u011fi olarak yeniden yap\u0131l\u0131r. E\u011fer orijinal iste\u011fin metodunu korumak istiyorsan\u0131z (\u00f6zellikle POST veya PUT gibi metotlar i\u00e7in), 307 veya 308 kullanmak daha g\u00fcvenlidir. Ancak \u00e7o\u011fu zaman API'lerde kal\u0131c\u0131 y\u00f6nlendirmeler i\u00e7in 301, ge\u00e7ici y\u00f6nlendirmeler i\u00e7in 302 tercih edilir, \u00f6zellikle de bu y\u00f6nlendirmeler genellikle GET istekleriyle tetiklendi\u011finde veya istemci davran\u0131\u015f\u0131n\u0131n bilindi\u011fi durumlarda.<\/p>\n API'lerinizde y\u00f6nlendirme kodlar\u0131n\u0131 do\u011fru kullanmak, kaynaklar\u0131n\u0131z\u0131n esnekli\u011fini art\u0131r\u0131r, URL de\u011fi\u015fikliklerini y\u00f6netmeyi kolayla\u015ft\u0131r\u0131r ve istemci entegrasyonlar\u0131n\u0131n daha sa\u011flam olmas\u0131n\u0131 sa\u011flar. Ancak, gereksiz y\u00f6nlendirmelerden ka\u00e7\u0131nmak, API performans\u0131n\u0131 olumlu y\u00f6nde etkiler, zira her y\u00f6nlendirme, istemci i\u00e7in ek bir HTTP iste\u011fi anlam\u0131na gelir.<\/p>\n 4xx s\u0131n\u0131f\u0131 durum kodlar\u0131, API geli\u015ftirme s\u00fcrecinde belki de en s\u0131k kar\u015f\u0131la\u015f\u0131lan ve do\u011fru y\u00f6netilmesi gereken hatalar\u0131 temsil eder. Bu kodlar, istemcinin (API'nizi kullanan uygulama) iste\u011finde bir sorun oldu\u011funu, yani sunucunun iste\u011fi i\u015fleyemedi\u011fini veya reddetti\u011fini g\u00f6sterir. Bu hatalar\u0131 do\u011fru bir \u015fekilde d\u00f6nd\u00fcrmek, API'nizin kullan\u0131c\u0131 dostu olmas\u0131n\u0131, hata ay\u0131klama s\u00fcrecini h\u0131zland\u0131rmas\u0131n\u0131 ve istemci uygulamalar\u0131n\u0131n daha ak\u0131ll\u0131 kararlar almas\u0131n\u0131 sa\u011flar.<\/p>\n 400 Bad Request, istemcinin sunucuya g\u00f6nderdi\u011fi iste\u011fin genel olarak ge\u00e7ersiz oldu\u011funu belirtir. Bu, iste\u011fin s\u00f6zdizimsel olarak hatal\u0131 oldu\u011fu, eksik veya yanl\u0131\u015f parametreler i\u00e7erdi\u011fi veya ba\u015fl\u0131klar\u0131n hatal\u0131 oldu\u011fu durumlarda kullan\u0131l\u0131r. Bu, genellikle istemcinin iste\u011fi d\u00fczeltmesi gerekti\u011fini g\u00f6steren genel bir hatad\u0131r.<\/p>\n Kullan\u0131m Senaryosu:<\/strong> Bir kullan\u0131c\u0131 kayd\u0131 API'sine e-posta format\u0131 yanl\u0131\u015f g\u00f6nderildi\u011finde:<\/p>\n <\/code><\/p>\n Bu yan\u0131t, istemcinin tam olarak nerede hata yapt\u0131\u011f\u0131n\u0131 a\u00e7\u0131k\u00e7a belirtir ve hatay\u0131 d\u00fczeltmesi i\u00e7in gerekli bilgiyi sa\u011flar.<\/p>\n 401 Unauthorized, bir iste\u011fin kimlik do\u011frulamas\u0131 gerektirdi\u011fini ancak istemcinin kimlik bilgilerini sa\u011flamad\u0131\u011f\u0131n\u0131 veya sa\u011flad\u0131\u011f\u0131 kimlik bilgilerinin ge\u00e7ersiz oldu\u011funu belirtir. Genellikle bir Vaka Analizi: Bankac\u0131l\u0131k Uygulamas\u0131nda Hatal\u0131 Kimlik Do\u011frulama<\/strong><\/p>\n Bir mobil bankac\u0131l\u0131k uygulamas\u0131n\u0131n, kullan\u0131c\u0131n\u0131n hesap bakiyesini sorgulamak i\u00e7in bir API'ye istek g\u00f6nderdi\u011fini varsayal\u0131m. E\u011fer yetkilendirme token'\u0131 eksik veya ge\u00e7ersizse:<\/p>\n <\/code><\/p>\n \u0130stemci bu yan\u0131t\u0131 ald\u0131\u011f\u0131nda, kullan\u0131c\u0131dan tekrar giri\u015f yapmas\u0131n\u0131 isteyebilir veya ge\u00e7erli bir token ile iste\u011fi yenileyebilir.<\/p>\n 403 Forbidden, kimlik do\u011frulamas\u0131 yap\u0131lm\u0131\u015f olsa bile, istemcinin istenen kayna\u011fa eri\u015fim iznine sahip olmad\u0131\u011f\u0131n\u0131 belirtir. Yani, istemcinin kim oldu\u011fu bilinir, ancak o eylemi ger\u00e7ekle\u015ftirmeye veya o kayna\u011fa eri\u015fmeye yetkili de\u011fildir.<\/p>\n Kullan\u0131m Senaryosu:<\/strong> Bir kullan\u0131c\u0131n\u0131n sadece kendi hesap bilgilerini g\u00f6rebildi\u011fi, ancak ba\u015fka bir kullan\u0131c\u0131n\u0131n bilgilerine eri\u015fmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131 durum:<\/p>\n <\/code><\/p>\n Bu, yetkilendirme (authorization) ile ilgili bir hatad\u0131r, kimlik do\u011frulama (authentication) ile de\u011fil.<\/p>\n 404 Not Found, sunucunun istenen kayna\u011f\u0131 (URL) bulamad\u0131\u011f\u0131n\u0131 belirtir. Bu, en yayg\u0131n HTTP hatalar\u0131ndan biridir ve genellikle istemcinin yanl\u0131\u015f bir URL'ye istek g\u00f6nderdi\u011fini g\u00f6sterir.<\/p>\n Kullan\u0131m Senaryosu:<\/strong> Ge\u00e7ersiz bir \u00fcr\u00fcn ID'si ile \u00fcr\u00fcn detay\u0131 sorgulama:<\/p>\n <\/code><\/p>\n * 405 Method Not Allowed:<\/strong> \u0130stemcinin kulland\u0131\u011f\u0131 HTTP metodu (GET, POST vb.) belirli bir kaynak i\u00e7in ge\u00e7erli olmad\u0131\u011f\u0131nda d\u00f6nd\u00fcr\u00fcl\u00fcr. \u00d6rne\u011fin, sadece GET destekleyen bir u\u00e7 noktaya POST iste\u011fi yap\u0131ld\u0131\u011f\u0131nda. API geli\u015ftirirken 4xx hatalar\u0131n\u0131 do\u011fru ve a\u00e7\u0131klay\u0131c\u0131 bir \u015fekilde d\u00f6nd\u00fcrmek, API'nizin d\u0131\u015f d\u00fcnyaya kar\u015f\u0131 net bir aray\u00fcze sahip olmas\u0131n\u0131 sa\u011flar. Her bir hatan\u0131n nedenini ve nas\u0131l d\u00fczeltilece\u011fini a\u00e7\u0131klayan detayl\u0131 hata mesajlar\u0131 sunmak, entegrasyon s\u00fcrecini b\u00fcy\u00fck \u00f6l\u00e7\u00fcde kolayla\u015ft\u0131r\u0131r.<\/p>\n 5xx s\u0131n\u0131f\u0131 HTTP durum kodlar\u0131, istemcinin iste\u011fi do\u011fru olsa bile sunucunun iste\u011fi yerine getiremedi\u011fi durumlar\u0131 i\u015faret eder. Bu hatalar, genellikle sunucu taraf\u0131ndaki bir problemden kaynaklan\u0131r; yani API'nizin kendisinde, veritaban\u0131nda, entegre oldu\u011fu ba\u015fka bir serviste veya sunucu altyap\u0131s\u0131nda bir sorun var demektir. 5xx hatalar\u0131n\u0131 anlamak ve y\u00f6netmek, API'nizin g\u00fcvenilirli\u011fini sa\u011flamak ve kritik kesintileri en aza indirmek i\u00e7in hayati \u00f6neme sahiptir.<\/p>\n 500 Internal Server Error, en genel ve en az bilgilendirici sunucu hatas\u0131d\u0131r. Sunucunun iste\u011fi i\u015flerken beklenmedik bir durumla kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131 ve iste\u011fi tamamlayamad\u0131\u011f\u0131n\u0131 belirtir. Bu hata, genellikle yakalanmayan istisnalar, kod hatalar\u0131 veya sunucunun i\u00e7 mant\u0131\u011f\u0131ndaki sorunlar nedeniyle ortaya \u00e7\u0131kar. \u0130stemciye bu hatay\u0131 d\u00f6nd\u00fcr\u00fcrken, i\u00e7 hata detaylar\u0131n\u0131 if\u015fa etmek g\u00fcvenlik riski olu\u015fturabilece\u011finden dikkatli olunmal\u0131d\u0131r.<\/p>\n Vaka Analizi: Mikroservis Mimarisinde Bir Servis Kesintisi<\/strong><\/p>\n Bir e-ticaret uygulamas\u0131nda, \u00fcr\u00fcn detaylar\u0131n\u0131 getiren API'nin, bir arka u\u00e7taki stok servisinden veri almas\u0131 gerekti\u011fini varsayal\u0131m. E\u011fer stok servisi ula\u015f\u0131lamaz hale gelirse, \u00fcr\u00fcn detay\u0131 API'si 500 hatas\u0131 d\u00f6nd\u00fcrebilir:<\/p>\n <\/code><\/p>\n Bu t\u00fcr durumlarda, istemciye genel bir hata mesaj\u0131 sunulmal\u0131, ancak sunucu loglar\u0131nda hatan\u0131n k\u00f6k nedeni ayr\u0131nt\u0131l\u0131 olarak kaydedilmelidir.<\/p>\n 502 Bad Gateway, bir sunucunun (genellikle bir proxy veya gateway), yukar\u0131 ak\u0131\u015f (upstream) sunucusundan ge\u00e7ersiz bir yan\u0131t ald\u0131\u011f\u0131n\u0131 belirtir. Bu, genellikle bir API gateway'inin veya bir y\u00fck dengeleyicinin, arkas\u0131ndaki ger\u00e7ek sunuculardan hatal\u0131 veya hi\u00e7 yan\u0131t alamad\u0131\u011f\u0131 durumlarda meydana gelir.<\/p>\n Kullan\u0131m Senaryosu:<\/strong> Nginx gibi bir reverse proxy'nin, arkas\u0131ndaki uygulama sunucusuna eri\u015fememesi.<\/p>\n <\/code><\/p>\n Bu hata, genellikle a\u011f yap\u0131land\u0131rmas\u0131 veya arka u\u00e7 servislerinin kesintiye u\u011framas\u0131yla ili\u015fkilidir.<\/p>\n 503 Service Unavailable, sunucunun iste\u011fi \u015fu anda i\u015fleyemedi\u011fini belirtir, \u00e7\u00fcnk\u00fc sunucu ge\u00e7ici olarak a\u015f\u0131r\u0131 y\u00fcklenmi\u015f veya bak\u0131m nedeniyle kullan\u0131lam\u0131yor. Bu durum genellikle ge\u00e7icidir ve sunucuya bir Kullan\u0131m Senaryosu:<\/strong> API sunucusunun planl\u0131 bir bak\u0131mda olmas\u0131 veya ani trafik yo\u011funlu\u011fu nedeniyle kaynaklar\u0131n\u0131n yetersiz kalmas\u0131.<\/p>\n <\/code><\/p>\n 504 Gateway Timeout, sunucunun (bir gateway veya proxy olarak hareket ederken), yukar\u0131 ak\u0131\u015f sunucusundan zaman\u0131nda yan\u0131t alamad\u0131\u011f\u0131n\u0131 belirtir. Bu, genellikle API'nizin ba\u015fka bir servisten veri beklerken o servisin \u00e7ok yava\u015f yan\u0131t vermesi veya hi\u00e7 yan\u0131t vermemesi durumunda ortaya \u00e7\u0131kar.<\/p>\n Kullan\u0131m Senaryosu:<\/strong> Bir API'nin, karma\u015f\u0131k bir rapor olu\u015fturmak i\u00e7in ba\u015fka bir uzun s\u00fcreli \u00e7al\u0131\u015fan arka plan servisine ba\u011f\u0131ml\u0131 olmas\u0131 ve bu servisin belirli bir s\u00fcre i\u00e7inde yan\u0131t vermemesi.<\/p>\n <\/code><\/p>\n 5xx hatalar\u0131n\u0131n do\u011fru bir \u015fekilde ele al\u0131nmas\u0131, API'nizin dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 ve hata tolerans\u0131n\u0131 art\u0131r\u0131r. Bu hatalar\u0131 proaktif bir \u015fekilde izlemek (monitoring), loglamak ve alarm sistemleriyle entegre etmek, olas\u0131 kesintileri h\u0131zla tespit edip \u00e7\u00f6zmek i\u00e7in kritik \u00f6neme sahiptir. \u0130stemcilere do\u011fru 5xx kodlar\u0131n\u0131 ve anla\u015f\u0131l\u0131r mesajlar\u0131 d\u00f6nd\u00fcrmek, onlar\u0131n hatal\u0131 istekler g\u00f6ndermesini engellemese de, problemin sunucu taraf\u0131nda oldu\u011funu bilmelerini sa\u011flayarak gereksiz istemci taraf\u0131 hata ay\u0131klama \u00e7abalar\u0131n\u0131 \u00f6nler.<\/p>\n API geli\u015ftirme, sadece i\u015flevsellik sa\u011flamakla kalmaz, ayn\u0131 zamanda kullan\u0131c\u0131 dostu, esnek ve s\u00fcrd\u00fcr\u00fclebilir bir aray\u00fcz sunmay\u0131 da gerektirir. HTTP durum kodlar\u0131, bu ileri seviye tasar\u0131m prensiplerini destekleyen g\u00fc\u00e7l\u00fc bir ara\u00e7t\u0131r. Durum kodlar\u0131n\u0131 ak\u0131ll\u0131ca kullanmak, API'nizin davran\u0131\u015f\u0131n\u0131 daha tutarl\u0131 hale getirir, hata y\u00f6netimini kolayla\u015ft\u0131r\u0131r ve hatta performans\u0131 optimize etmenize yard\u0131mc\u0131 olabilir.<\/p>\n Bir\u00e7ok geli\u015ftirici, 400 Bad Request veya 500 Internal Server Error gibi genel durum kodlar\u0131n\u0131 d\u00f6nd\u00fcr\u00fcp, hatan\u0131n ger\u00e7ek nedenini yan\u0131t g\u00f6vdesinde \u00f6zel bir JSON yap\u0131s\u0131yla a\u00e7\u0131klamay\u0131 tercih eder. Bu yakla\u015f\u0131m, hatan\u0131n detaylar\u0131n\u0131 istemciye sunarken, HTTP standard\u0131na da uyumu korur.<\/p>\n \u00d6rnek Bir Hata Yap\u0131s\u0131:<\/strong><\/p>\n <\/code><\/p>\n Bu yap\u0131, istemcinin hatay\u0131 programatik olarak ayr\u0131\u015ft\u0131rmas\u0131na ve kullan\u0131c\u0131 aray\u00fcz\u00fcnde ilgili alanlara y\u00f6nelik spesifik mesajlar g\u00f6stermesine olanak tan\u0131r. Ancak her \u00f6zel durum i\u00e7in yeni bir HTTP kodu icat etmek yerine, mevcut 4xx ve 5xx kodlar\u0131n\u0131 geni\u015fleten bu t\u00fcr standartla\u015ft\u0131r\u0131lm\u0131\u015f hata g\u00f6vdeleri daha pratik ve s\u00fcrd\u00fcr\u00fclebilirdir.<\/p>\n Idempotency, bir iste\u011fin birden fazla kez g\u00f6nderilmesinin, tek bir kez g\u00f6nderilmesiyle ayn\u0131 sonuca sahip olmas\u0131 anlam\u0131na gelir. GET, PUT, DELETE gibi HTTP metotlar\u0131 do\u011falar\u0131 gere\u011fi idempotenttir. POST ise genellikle de\u011fildir, \u00e7\u00fcnk\u00fc her POST iste\u011fi genellikle yeni bir kaynak olu\u015fturur.<\/p>\n Bir API'de PUT veya DELETE iste\u011fiyle bir kayna\u011f\u0131 g\u00fcncellemeye veya silmeye \u00e7al\u0131\u015f\u0131rken, kaynak zaten yoksa veya zaten g\u00fcncelse ne yapmal\u0131s\u0131n\u0131z?<\/p>\n * PUT\/PATCH (G\u00fcncelleme):<\/strong> Bir kaynak g\u00fcncellendi\u011finde 200 OK veya 204 No Content d\u00f6nd\u00fcr\u00fclmelidir. E\u011fer g\u00fcncellemeye \u00e7al\u0131\u015f\u0131lan kaynak mevcut de\u011filse, genellikle 404 Not Found d\u00f6nd\u00fcr\u00fcl\u00fcr. Ancak baz\u0131 durumlarda, PUT metodunun \"upsert\" (varsa g\u00fcncelle, yoksa olu\u015ftur) davran\u0131\u015f\u0131 g\u00f6stermesi istenebilir; bu durumda, kaynak yoksa 201 Created d\u00f6nd\u00fcr\u00fclebilir. <\/code><\/p>\n API'nizi versiyonlad\u0131\u011f\u0131n\u0131zda (\u00f6rne\u011fin <\/code><\/p>\n Bu, istemcilerin eski entegrasyonlar\u0131n\u0131 g\u00fcncellemeye zorlar ve API'nizin temiz ve g\u00fcncel kalmas\u0131na yard\u0131mc\u0131 olur. \u0130leri seviye API tasar\u0131m\u0131nda durum kodlar\u0131n\u0131 bu \u015fekilde stratejik olarak kullanmak, API'nizin sadece i\u015flevsel de\u011fil, ayn\u0131 zamanda robust ve gelece\u011fe d\u00f6n\u00fck olmas\u0131n\u0131 sa\u011flar.<\/p>\n Mobil uygulamalar, API'lerinizin en yayg\u0131n t\u00fcketicilerinden biridir. Bu nedenle, API yan\u0131tlar\u0131n\u0131z\u0131n ve \u00f6zellikle hata mesajlar\u0131n\u0131z\u0131n mobil cihazlarda verimli ve kullan\u0131c\u0131 dostu bir \u015fekilde i\u015flenebilir olmas\u0131 b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. Mobil uygulamalar genellikle d\u00fc\u015f\u00fck bant geni\u015fli\u011fi, de\u011fi\u015fken a\u011f ko\u015fullar\u0131 ve k\u0131s\u0131tl\u0131 i\u015flem g\u00fcc\u00fcyle \u00e7al\u0131\u015f\u0131r, bu da API tasar\u0131m\u0131nda \u00f6zel yakla\u015f\u0131mlar gerektirir.<\/p>\n Daha \u00f6nce de belirtti\u011fimiz gibi, genel HTTP durum kodlar\u0131na ek olarak, yan\u0131t g\u00f6vdesinde detayl\u0131 hata bilgisi sunmak mobil uygulamalar i\u00e7in vazge\u00e7ilmezdir. Mobil geli\u015ftiricilerin bu hata mesajlar\u0131n\u0131 kolayca ayr\u0131\u015ft\u0131r\u0131p kullan\u0131c\u0131ya anlaml\u0131 geri bildirimler sunabilmesi i\u00e7in hata yap\u0131lar\u0131n\u0131n standartla\u015ft\u0131r\u0131lmas\u0131 gerekir.<\/p>\n \u00d6nerilen bir JSON hata yap\u0131s\u0131 \u015funlar\u0131 i\u00e7erebilir:<\/p>\n * <\/code><\/p>\n Mobil uygulama, bu yap\u0131y\u0131 kullanarak hata mesajlar\u0131n\u0131 kullan\u0131c\u0131ya anla\u015f\u0131l\u0131r bir dilde ve do\u011fru ba\u011flamda sunabilir (\u00f6rne\u011fin, kullan\u0131c\u0131 ad\u0131 alan\u0131n\u0131n alt\u0131nda \"Kullan\u0131c\u0131 ad\u0131 bo\u015f b\u0131rak\u0131lamaz\" uyar\u0131s\u0131n\u0131 g\u00f6stermek).<\/p>\n Mobil uygulamalar\u0131n hata y\u00f6netimi, kullan\u0131c\u0131 deneyimini do\u011frudan etkiler. API'den gelen 4xx ve 5xx hatalar\u0131n\u0131 nas\u0131l y\u00f6netece\u011finize dair baz\u0131 ipu\u00e7lar\u0131:<\/p>\n 1. Anla\u015f\u0131l\u0131r Mesajlar:<\/strong> API'den gelen teknik hata mesajlar\u0131n\u0131 do\u011frudan kullan\u0131c\u0131ya g\u00f6stermek yerine, daha kullan\u0131c\u0131 dostu ve anla\u015f\u0131l\u0131r mesajlara \u00e7evirin. \u00d6rne\u011fin, \"VALIDATION_FAILED\" kodunu \"Girdi\u011finiz bilgilerde bir sorun var\" olarak \u00e7evirin. Her ne kadar API'ler genellikle JSON veya XML yan\u0131tlar\u0131 d\u00f6nse de, baz\u0131 durumlarda API'nizden gelen bir yan\u0131t\u0131n do\u011frudan bir web g\u00f6r\u00fcn\u00fcm\u00fcnde veya hata sayfas\u0131nda g\u00f6sterilmesi gerekebilir. Bu senaryolarda, mobil uyumlu HTML stilleri kullanmak, hata mesajlar\u0131n\u0131n farkl\u0131 ekran boyutlar\u0131nda do\u011fru g\u00f6r\u00fcnt\u00fclenmesini sa\u011flar.<\/p>\n A\u015fa\u011f\u0131daki CSS \u00f6rne\u011fi, bir hata mesaj\u0131 kapsay\u0131c\u0131s\u0131n\u0131n mobil cihazlarda nas\u0131l daha k\u00fc\u00e7\u00fck yaz\u0131 tipleriyle ve uygun dolgularla g\u00f6r\u00fcnt\u00fclenebilece\u011fini g\u00f6sterir:<\/p>\n
\n* 2xx (Ba\u015far\u0131l\u0131 Yan\u0131tlar):<\/strong> \u0130stek ba\u015far\u0131yla al\u0131nd\u0131, anla\u015f\u0131ld\u0131 ve kabul edildi.
\n* 3xx (Y\u00f6nlendirme Yan\u0131tlar\u0131):<\/strong> \u0130stek tamamlanmak i\u00e7in ek eylem gerektiriyor. Kaynak ta\u015f\u0131nm\u0131\u015f olabilir.
\n* 4xx (\u0130stemci Hatalar\u0131):<\/strong> \u0130stek ge\u00e7ersiz s\u00f6zdizimi nedeniyle sunucu taraf\u0131ndan anla\u015f\u0131lamad\u0131 veya i\u015flenemedi. Genellikle istemcinin hatas\u0131d\u0131r.
\n* 5xx (Sunucu Hatalar\u0131):<\/strong> Sunucu, ge\u00e7erli bir iste\u011fi yerine getiremedi. Sorun sunucu taraf\u0131ndad\u0131r.<\/p>\nBa\u015far\u0131l\u0131 Yan\u0131tlar (2xx): \u0130stekleriniz Sorunsuz \u00c7al\u0131\u015f\u0131yor mu?<\/h2>\n
200 OK: Her \u015eey Yolunda m\u0131?<\/h3>\n
\/\/ \u0130stemci taraf\u0131 (\u00d6rnek JavaScript kodu)\nfetch('\/api\/sepetim')\n .then(response => {\n if (response.status === 200) {\n return response.json();\n }\n \/\/ Hata durumu, \u00f6rne\u011fin 404 e\u011fer sepet bulunamazsa\n throw new Error('Sepet getirilirken bir sorun olu\u015ftu.');\n })\n .then(data => {\n console.log('Sepet i\u00e7eri\u011fi:', data);\n \/\/ Sepeti kullan\u0131c\u0131 aray\u00fcz\u00fcnde g\u00f6ster\n })\n .catch(error => {\n console.error('Hata:', error);\n });<\/pre>\nresponse.status === 200<\/code> kontrol\u00fc, sepet i\u00e7eri\u011finin ba\u015far\u0131yla al\u0131nd\u0131\u011f\u0131n\u0131 ve istemcinin bu veriyi g\u00fcvenle kullanabilece\u011fini g\u00f6sterir.<\/p>\n201 Created: Yeni Bir Kaynak Olu\u015fturuldu mu?<\/h3>\n
Location<\/code> ba\u015fl\u0131\u011f\u0131 ve kayna\u011f\u0131n kendisini i\u00e7eren bir yan\u0131t g\u00f6vdesi ile birlikte gelir. Bu, istemcinin yeni kayna\u011fa hemen eri\u015febilmesini sa\u011flar.<\/p>\n\/\/ \u0130stemci taraf\u0131\nconst siparisData = {\n urunler: [{ id: 1, adet: 2 }, { id: 3, adet: 1 }],\n adres: \"\u0130stanbul, T\u00fcrkiye\"\n};\n\nfetch('\/api\/siparisler', {\n method: 'POST',\n headers: {\n 'Content-Type': 'application\/json'\n },\n body: JSON.stringify(siparisData)\n})\n.then(response => {\n if (response.status === 201) {\n const locationHeader = response.headers.get('Location');\n console.log('Yeni sipari\u015f ba\u015far\u0131yla olu\u015fturuldu. Konum:', locationHeader);\n return response.json();\n }\n throw new Error('Sipari\u015f olu\u015fturulurken bir sorun olu\u015ftu.');\n})\n.then(data => {\n console.log('Olu\u015fturulan sipari\u015f detay\u0131:', data);\n \/\/ Kullan\u0131c\u0131y\u0131 yeni sipari\u015f sayfas\u0131na y\u00f6nlendir\n \/\/ window.location.href = data.url; \/\/ Location ba\u015fl\u0131\u011f\u0131 yerine yan\u0131ttaki URL kullan\u0131labilir\n})\n.catch(error => {\n console.error('Hata:', error);\n});<\/pre>\nLocation<\/code> ba\u015fl\u0131\u011f\u0131nda veya yan\u0131t g\u00f6vdesinde bir URL ile) belirtir.<\/p>\n204 No Content: Yan\u0131t G\u00f6vdesine Gerek Yok mu?<\/h3>\n
\/\/ \u0130stemci taraf\u0131\nconst postId = 123;\nfetch(\/api\/gonderiler\/${postId}<\/code>, {\n method: 'DELETE',\n headers: {\n 'Authorization': 'Bearer ' + token\n }\n})\n.then(response => {\n if (response.status === 204) {\n console.log(G\u00f6nderi #${postId} ba\u015far\u0131yla silindi.<\/code>);\n \/\/ Kullan\u0131c\u0131 aray\u00fcz\u00fcnden g\u00f6nderiyi kald\u0131r\n } else if (response.status === 404) {\n console.warn(G\u00f6nderi #${postId} bulunamad\u0131.<\/code>);\n } else {\n throw new Error('G\u00f6nderi silinirken bir sorun olu\u015ftu.');\n }\n})\n.catch(error => {\n console.error('Hata:', error);\n});<\/pre>\nY\u00f6nlendirme Yan\u0131tlar\u0131 (3xx): Kullan\u0131c\u0131y\u0131 veya \u0130stemciyi Do\u011fru Yere Nas\u0131l Y\u00f6nlendirmeliyiz?<\/h2>\n
301 Moved Permanently: Kal\u0131c\u0131 Olarak Ta\u015f\u0131nd\u0131 m\u0131?<\/h3>\n
Location<\/code> ba\u015fl\u0131\u011f\u0131nda yeni URL'yi i\u00e7erir. Taray\u0131c\u0131lar ve baz\u0131 API istemcileri, bu y\u00f6nlendirmeyi otomatik olarak \u00f6nbelle\u011fe al\u0131r ve sonraki istekleri do\u011frudan yeni URL'ye yapar.<\/p>\n\/api\/v1\/urunler<\/code> u\u00e7 noktas\u0131n\u0131 \/api\/urunler<\/code> olarak de\u011fi\u015ftirdiniz.<\/p>\nHTTP\/1.1 301 Moved Permanently\nLocation: https:\/\/api.example.com\/api\/urunler<\/pre>\n302 Found (Ge\u00e7ici) veya 303 See Other (POST Sonras\u0131 Y\u00f6nlendirme): Ge\u00e7ici Bir Y\u00f6nlendirme mi?<\/h3>\n
\n* 303 See Other:<\/strong> \u00d6zellikle bir POST iste\u011finin ba\u015far\u0131yla i\u015flenmesinden sonra, istemciyi farkl\u0131 bir kayna\u011fa (genellikle bir GET iste\u011fi ile eri\u015filebilecek bir onay veya sonu\u00e7 sayfas\u0131na) y\u00f6nlendirmek i\u00e7in kullan\u0131l\u0131r. Bu, taray\u0131c\u0131n\u0131n \"yenile\" d\u00fc\u011fmesine bas\u0131ld\u0131\u011f\u0131nda POST iste\u011finin tekrar g\u00f6nderilmesini \u00f6nler (PRG \u2013 Post\/Redirect\/Get deseni).<\/p>\n\/\/ Sunucu taraf\u0131 (\u00d6rnek Node.js \/ Express kodu)\napp.post('\/api\/kayit', (req, res) => {\n \/\/ Veritaban\u0131na kaydetme i\u015flemi\n const yeniKullaniciId = veritabaninaKaydet(req.body);\n \/\/ Kay\u0131t ba\u015far\u0131l\u0131 oldu, kullan\u0131c\u0131y\u0131 onay sayfas\u0131na y\u00f6nlendir\n res.redirect(303, \/kayit-basarili?id=${yeniKullaniciId}<\/code>);\n});<\/pre>\nres.redirect(303, ...)<\/code> ile kullan\u0131c\u0131, kay\u0131t i\u015fleminin ba\u015far\u0131l\u0131 oldu\u011funu g\u00f6steren bir GET iste\u011fi ile \/kayit-basarili<\/code> URL'sine y\u00f6nlendirilir. Bu, kullan\u0131c\u0131 deneyimi a\u00e7\u0131s\u0131ndan daha temiz ve g\u00fcvenlidir.<\/p>\n307 Temporary Redirect ve 308 Permanent Redirect: Metot G\u00fcvenli\u011fi ile Y\u00f6nlendirme<\/h3>\n
\n* 308 Permanent Redirect:<\/strong> 301'e benzer \u015fekilde kal\u0131c\u0131 bir y\u00f6nlendirmedir, ancak yine metot g\u00fcvenli\u011fini garanti eder. Orijinal iste\u011fin metodu ne olursa olsun, yeni URL'ye ayn\u0131 metot ile istek yap\u0131l\u0131r.<\/p>\n\u0130stemci Hatalar\u0131 (4xx): Kullan\u0131c\u0131 Nerede Yanl\u0131\u015f Yapt\u0131?<\/h2>\n
400 Bad Request: \u0130stek Ge\u00e7ersiz mi?<\/h3>\n
HTTP\/1.1 400 Bad Request\nContent-Type: application\/json\n\n{\n \"status\": 400,\n \"code\": \"INVALID_EMAIL_FORMAT\",\n \"message\": \"G\u00f6nderilen e-posta adresi ge\u00e7ersiz formatta.\",\n \"details\": [\n { \"field\": \"email\", \"message\": \"Ge\u00e7erli bir e-posta adresi girin.\" }\n ]\n}<\/pre>\n401 Unauthorized: Kimlik Do\u011frulama Ba\u015far\u0131s\u0131z m\u0131?<\/h3>\n
WWW-Authenticate<\/code> ba\u015fl\u0131\u011f\u0131 ile birlikte gelir, bu da istemciye hangi kimlik do\u011frulama y\u00f6nteminin beklendi\u011fini bildirir.<\/p>\nHTTP\/1.1 401 Unauthorized\nWWW-Authenticate: Bearer realm=\"API Eri\u015fimi\"\nContent-Type: application\/json\n\n{\n \"status\": 401,\n \"code\": \"AUTH_REQUIRED\",\n \"message\": \"Bu kayna\u011fa eri\u015fim i\u00e7in kimlik do\u011frulama gereklidir.\"\n}<\/pre>\n403 Forbidden: Yetkiniz Yok mu?<\/h3>\n
HTTP\/1.1 403 Forbidden\nContent-Type: application\/json\n\n{\n \"status\": 403,\n \"code\": \"PERMISSION_DENIED\",\n \"message\": \"Bu kayna\u011fa eri\u015fim izniniz yok.\"\n}<\/pre>\n404 Not Found: Kaynak Bulunamad\u0131 m\u0131?<\/h3>\n
HTTP\/1.1 404 Not Found\nContent-Type: application\/json\n\n{\n \"status\": 404,\n \"code\": \"RESOURCE_NOT_FOUND\",\n \"message\": \"\u0130stenen \u00fcr\u00fcn bulunamad\u0131.\"\n}<\/pre>\nDi\u011fer \u00d6nemli 4xx Kodlar\u0131:<\/h3>\n
\n* 409 Conflict:<\/strong> Bir iste\u011fin, kayna\u011f\u0131n mevcut durumuyla \u00e7ak\u0131\u015ft\u0131\u011f\u0131n\u0131 belirtir. \u00d6rne\u011fin, zaten var olan bir kullan\u0131c\u0131 ad\u0131yla yeni bir kullan\u0131c\u0131 olu\u015fturmaya \u00e7al\u0131\u015f\u0131ld\u0131\u011f\u0131nda.
\n* 429 Too Many Requests:<\/strong> \u0130stemcinin belirli bir zaman diliminde \u00e7ok fazla istek g\u00f6nderdi\u011fini (oran s\u0131n\u0131rlamas\u0131 ihlali) belirtir. Genellikle bir Retry-After<\/code> ba\u015fl\u0131\u011f\u0131 ile birlikte gelir.<\/p>\nSunucu Hatalar\u0131 (5xx): Bizim Taraf\u0131m\u0131zda Neler Ters Gidiyor?<\/h2>\n
500 Internal Server Error: Ne Oldu\u011funu Bilmiyor muyuz?<\/h3>\n
HTTP\/1.1 500 Internal Server Error\nContent-Type: application\/json\n\n{\n \"status\": 500,\n \"code\": \"INTERNAL_SERVER_ERROR\",\n \"message\": \"Bir hata olu\u015ftu, l\u00fctfen daha sonra tekrar deneyin.\"\n \/\/ G\u00fcvenlik nedeniyle daha fazla detay verilmiyor\n}<\/pre>\n502 Bad Gateway: Proxy veya Gateway Sorunu mu?<\/h3>\n
HTTP\/1.1 502 Bad Gateway<\/pre>\n503 Service Unavailable: Bak\u0131m m\u0131 Var, A\u015f\u0131r\u0131 Y\u00fck m\u00fc?<\/h3>\n
Retry-After<\/code> ba\u015fl\u0131\u011f\u0131 eklenerek istemcilere ne zaman tekrar denemeleri gerekti\u011fi bildirilebilir.<\/p>\nHTTP\/1.1 503 Service Unavailable\nRetry-After: 3600 \/\/ Bir saat sonra tekrar dene\n\nContent-Type: application\/json\n{\n \"status\": 503,\n \"code\": \"SERVICE_UNAVAILABLE\",\n \"message\": \"API ge\u00e7ici olarak kullan\u0131lam\u0131yor. L\u00fctfen bir s\u00fcre sonra tekrar deneyin.\"\n}<\/pre>\nRetry-After<\/code> ba\u015fl\u0131\u011f\u0131, istemcilerin agresif bir \u015fekilde yeniden deneme yapmas\u0131n\u0131 \u00f6nleyerek sunucu \u00fczerindeki y\u00fck\u00fc hafifletmeye yard\u0131mc\u0131 olur.<\/p>\n504 Gateway Timeout: \u0130stek Zaman A\u015f\u0131m\u0131na m\u0131 U\u011frad\u0131?<\/h3>\n
HTTP\/1.1 504 Gateway Timeout\nContent-Type: application\/json\n\n{\n \"status\": 504,\n \"code\": \"GATEWAY_TIMEOUT\",\n \"message\": \"\u0130stek i\u015flenirken zaman a\u015f\u0131m\u0131na u\u011frad\u0131. L\u00fctfen daha sonra tekrar deneyin.\"\n}<\/pre>\n\u0130leri Seviye API Tasar\u0131m\u0131 \u0130\u00e7in Durum Kodlar\u0131n\u0131 Ak\u0131ll\u0131ca Kullanmak<\/h2>\n
\u00d6zel Hata Mesajlar\u0131 ve Standart Kodlar Aras\u0131ndaki Denge<\/h3>\n
{\n \"status\": 400,\n \"code\": \"VALIDATION_ERROR\",\n \"message\": \"\u0130stek g\u00f6vdesindeki veriler ge\u00e7erli de\u011fil.\",\n \"details\": [\n {\n \"field\": \"username\",\n \"message\": \"Kullan\u0131c\u0131 ad\u0131 en az 3 karakter olmal\u0131.\"\n },\n {\n \"field\": \"password\",\n \"message\": \"\u015eifre en az 8 karakter olmal\u0131 ve bir rakam i\u00e7ermelidir.\"\n }\n ],\n \"timestamp\": \"2023-10-27T10:30:00Z\"\n}<\/pre>\nIdempotency (Tekrarlanabilirlik) ve Durum Kodlar\u0131<\/h3>\n
\n* DELETE (Silme):<\/strong> Bir kaynak ba\u015far\u0131yla silindi\u011finde 204 No Content d\u00f6nd\u00fcr\u00fclmelidir. E\u011fer silinmek istenen kaynak zaten mevcut de\u011filse, yine 404 Not Found d\u00f6nd\u00fcrmek uygun olabilir. Alternatif olarak, i\u015flemin zaten istenen sonucu verdi\u011fini belirten 200 OK veya 204 No Content d\u00f6nd\u00fcrmek de kabul edilebilir, zira \"kayna\u011f\u0131n silinmi\u015f olmas\u0131n\u0131 sa\u011flamak\" amac\u0131na ula\u015f\u0131lm\u0131\u015ft\u0131r. Bu son yakla\u015f\u0131m, DELETE'i daha idempotent hale getirir.<\/p>\n\n\/\/ \u00d6rnek DELETE endpoint'i\napp.delete('\/api\/urunler\/:id', (req, res) => {\n const urunId = req.params.id;\n const silinen = veritabanindanSil(urunId); \/\/ Veritaban\u0131 i\u015flemi\n\n if (silinen) {\n res.status(204).send(); \/\/ Ba\u015far\u0131yla silindi, i\u00e7erik yok\n } else {\n \/\/ Kaynak zaten yoksa veya bulunamazsa\n res.status(404).json({ message: 'Silinecek \u00fcr\u00fcn bulunamad\u0131.' });\n \/\/ Alternatif olarak, idempotency i\u00e7in 204 de d\u00f6nebiliriz.\n \/\/ res.status(204).send(); \/\/ \"Zaten silinmi\u015fse de, amaca ula\u015f\u0131ld\u0131\"\n }\n});\n<\/pre>\nAPI Versiyonlama ve Durum Kodlar\u0131<\/h3>\n
\/api\/v1\/users<\/code>, \/api\/v2\/users<\/code>), eski versiyonlar\u0131n kald\u0131r\u0131lmas\u0131 gerekti\u011finde durum kodlar\u0131 devreye girer. Eski bir versiyon art\u0131k desteklenmiyorsa, istemcileri yeni versiyona y\u00f6nlendirmek i\u00e7in 301 Moved Permanently veya 308 Permanent Redirect kullan\u0131labilir. Ancak bu, istemcilerin eski versiyonu kullanmaya devam etmesini engellemeyebilir. Daha yayg\u0131n bir yakla\u015f\u0131m, eski versiyona yap\u0131lan isteklere 410 Gone (Kaynak Kal\u0131c\u0131 Olarak Kald\u0131r\u0131ld\u0131) yan\u0131t\u0131 d\u00f6nerek istemcilerin art\u0131k bu kayna\u011f\u0131 kullanmamas\u0131 gerekti\u011fini a\u00e7\u0131k\u00e7a belirtmektir.<\/p>\nHTTP\/1.1 410 Gone\nContent-Type: application\/json\n\n{\n \"status\": 410,\n \"code\": \"API_VERSION_DEPRECATED\",\n \"message\": \"Bu API versiyonu art\u0131k desteklenmiyor. L\u00fctfen yeni versiyona ge\u00e7in.\"\n}<\/pre>\nMobil Uyumlu API Yan\u0131tlar\u0131 ve Hata Y\u00f6netimi: Pratik Yakla\u015f\u0131mlar<\/h2>\n
JSON Hata Yap\u0131lar\u0131: Mobil Uygulamalar \u0130\u00e7in Standartla\u015ft\u0131rma<\/h3>\n
status<\/code>: HTTP durum kodu (\u00f6rn. 400).
\n* code<\/code>: Uygulama \u00f6zelinde bir hata kodu (\u00f6rn. INVALID_INPUT<\/code>, USER_EXISTS<\/code>). Bu, mobil uygulaman\u0131n hatay\u0131 programatik olarak tan\u0131mas\u0131na ve \u00f6zel bir i\u015flem yapmas\u0131na olanak tan\u0131r.
\n* message<\/code>: Geli\u015ftirici dostu, k\u0131sa bir hata a\u00e7\u0131klamas\u0131.
\n* details<\/code>: Hatan\u0131n daha spesifik nedenlerini i\u00e7eren bir dizi (array). \u00d6rne\u011fin, hangi alan\u0131n yanl\u0131\u015f oldu\u011funu veya hangi do\u011frulama kural\u0131n\u0131n ihlal edildi\u011fini belirtebilir. Bu, mobil uygulaman\u0131n ilgili giri\u015f alan\u0131n\u0131n yan\u0131nda hatay\u0131 g\u00f6stermesine yard\u0131mc\u0131 olur.
\n* timestamp<\/code>: Hatan\u0131n ne zaman olu\u015ftu\u011funu belirten zaman damgas\u0131.
\n* traceId<\/code>: E\u011fer bir distributed tracing (da\u011f\u0131t\u0131k izleme) sistemi kullan\u0131l\u0131yorsa, hatay\u0131 loglarda bulmay\u0131 kolayla\u015ft\u0131ran bir izleme kimli\u011fi.<\/p>\nHTTP\/1.1 400 Bad Request\nContent-Type: application\/json\n\n{\n \"status\": 400,\n \"code\": \"VALIDATION_FAILED\",\n \"message\": \"G\u00f6nderilen veriler do\u011frulama kurallar\u0131n\u0131 kar\u015f\u0131lam\u0131yor.\",\n \"details\": [\n {\n \"field\": \"username\",\n \"error\": \"Kullan\u0131c\u0131 ad\u0131 bo\u015f b\u0131rak\u0131lamaz.\"\n },\n {\n \"field\": \"email\",\n \"error\": \"Ge\u00e7ersiz e-posta format\u0131.\"\n }\n ],\n \"timestamp\": \"2023-10-27T11:00:00Z\",\n \"traceId\": \"abc123def456\"\n}<\/pre>\nMobil Uygulamalarda Hata G\u00f6r\u00fcnt\u00fcleme ve Kullan\u0131c\u0131 Deneyimi<\/h3>\n
\n2. Ba\u011flam Sa\u011flay\u0131n:<\/strong> Hatan\u0131n nerede oldu\u011funu belirtin. E\u011fer bir formda hata varsa, ilgili giri\u015f alan\u0131n\u0131n yan\u0131nda g\u00f6sterin. Genel bir hata ise, ge\u00e7ici bir bildirim (snackbar, toast) veya hata ekran\u0131 kullan\u0131n.
\n3. Tekrar Deneme Se\u00e7ene\u011fi:<\/strong> \u00d6zellikle 5xx hatalar\u0131 ve baz\u0131 4xx hatalar\u0131 (\u00f6rn. 429 Too Many Requests) i\u00e7in kullan\u0131c\u0131ya \"Tekrar Dene\" veya \"Yenile\" se\u00e7ene\u011fi sunun. Ancak, 401 veya 403 gibi kal\u0131c\u0131 hatalar i\u00e7in bu mant\u0131kl\u0131 olmayabilir; bu durumda kullan\u0131c\u0131y\u0131 oturum a\u00e7ma sayfas\u0131na y\u00f6nlendirmek daha uygun olabilir.
\n4. Uygulama \u0130\u00e7i Hata Kayd\u0131:<\/strong> Mobil uygulaman\u0131n kendisinde de kritik hatalar\u0131 loglayarak veya hata izleme ara\u00e7lar\u0131na (Firebase Crashlytics, Sentry) g\u00f6ndererek API hatalar\u0131n\u0131n mobil taraftaki etkilerini izleyin.<\/p>\nMobil Uyumlu HTML ve Hata Mesajlar\u0131 i\u00e7in Stil \u00d6rnekleri (API'ye Dolayl\u0131 Yakla\u015f\u0131m)<\/h3>\n