REST API Nedir, HTTP Metodları Ne Anlama Geliyor?

---

Bir entegrasyon dokümanında "RESTful API" ifadesini görüp de gerçekte hangi kurallara uyulduğunu merak ettiyseniz yalnız değilsiniz. Çoğu geliştirici "REST" sözcüğünü "HTTP üzerinden JSON döndüren servis" anlamında kullanıyor; oysa terimin kendi kaynağında biraz daha dar bir tanımı var.

Bu yazı REST'in ne olduğunu ve günlük kullanımda neden gevşetildiğini, konunun iki resmî kaynağına dayanarak anlatıyor.

REST'in resmî tanımı nedir?​

MDN'nin REST tanımına göre Representational State Transfer, dağıtık sistemleri verimli, güvenilir ve ölçeklenebilir kılmak için bir dizi mimari kısıtlamadır. Temel fikir, bir kaynağın (örneğin bir belge) standartlaştırılmış, dile bağlı olmayan istemci/sunucu etkileşimleri üzerinden aktarılması.

MDN burada önemli bir ayrım koyuyor: HTTP üzerinden çalışan servisler günlük dilde "RESTful API" olarak anılsa da, bu servislerin REST'in tüm mimari kısıtlamalarına uyması şart değil. Başlangıç seviyesinde "REST API" ifadesi çoğunlukla standart web araçlarıyla çağrılabilen bir HTTP servisi anlamına geliyor.

HTTP'nin kendi kuralları neyi tanımlıyor?​

REST'in dayandığı istemci/sunucu etkileşimi, RFC 9110 (HTTP Semantics) belgesinde ayrıntılı şekilde tanımlanıyor. Belgeye göre bir HTTP isteğinin hedefi "kaynak" olarak adlandırılıyor; HTTP kaynağın doğasını sınırlamıyor, yalnız bir arayüz tanımlıyor. Aynı kaynak, farklı "temsiller" (representation) biçiminde sunulabiliyor; REST'in adındaki "representational" ifadesi de buradan geliyor.

RFC 9110 ayrıca HTTP'nin stateless (durum tutmayan) bir protokol olduğunu belirtiyor: her istek mesajının anlamı kendi içinde çözülebiliyor, önceki isteklerle kurulan bir "oturum hafızası" HTTP'nin kendisinde yok. REST mimarisinin durumsuzluk ilkesi de bu özellikle örtüşüyor.

Temsil (representation) neden JSON'a mahkûm değil?​

RFC 9110'un tanımına göre bir temsil, "bir kaynağın geçmiş, şimdiki veya istenen durumunu yansıtmak için tasarlanan bilgi." Aynı kaynak farklı temsillerde sunulabiliyor; belge bunu formatla sınırlamıyor. Pratikte çoğu API JSON'u tercih ediyor çünkü tarayıcı ve sunucu tarafında ayrıştırması kolay, ama REST'in tanımı belirli bir veri formatını zorunlu kılmıyor; aynı kaynağın XML ya da başka bir temsille de sunulması RFC'nin tanımına aykırı değil.

Metodların anlamı sabit​

Aynı RFC, kaynak üzerinde yapılacak işlemleri metodlara bağlıyor:

• GET: Kaynağın temsilini almak için kullanılan, sunucuda değişiklik yapmayan bir metod.
• PUT: Gönderilen durumun kaynağa uygulanmasını isteyen bir metod.
• POST: Kaynağın işlemesi için veri gönderen bir metod.
• DELETE: Belirtilen kaynağın kaldırılmasını isteyen bir metod.

Bu tanımlar herhangi bir API'ye özgü değil; HTTP'nin kendisine ait. Bir servis kendini "REST API" olarak adlandırıyorsa bile GET isteğiyle veri değiştirmesi, bu temel semantiği ihlal ediyor demektir.

Sık karıştırılan nokta' Alıntı:

"RESTful" etiketi bir garanti değil; asıl kontrol GET'in veri değiştirmediğini, POST/PUT/DELETE'in ne yaptığını doğrulamaktan geçiyor.

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

Statelessness pratikte ne değiştiriyor?​

Durumsuzluk ilkesi, sunucunun istemciyle ilgili bir "önceki adım" bilgisini bellekte tutmaması anlamına geliyor. Her istek, kimlik doğrulama bilgisi dahil, kendi başına yeterli olmalı. Bu da yatay ölçeklenmeyi kolaylaştırıyor: istekler farklı sunuculara dağıtılsa bile hiçbiri "önceki isteği hangi sunucu karşıladı" bilgisine ihtiyaç duymuyor.

Bir API'nin sayfalama (pagination) davranışı da bu ilkeyle yakından ilişkili; sayfalama parametreleri her istekte yeniden gönderilmediğinde tutarsız sonuçlar ortaya çıkabiliyor. Bu tür bir aksaklığı API sayfalamasında kayıtların neden eksildiğini ele aldığımız yazıda ayrıntılı işlemiştik.

Kaynak tasarımında sık yapılan hata​

REST kaynak odaklı çalışıyor: URL bir eylemi değil bir varlığı temsil etmeli (/kullanicilar/42 gibi), eylem ise HTTP metoduyla belirtilmeli. "/kullanici-sil?id=42" gibi bir GET isteğiyle silme işlemi yapmak, hem RFC 9110'un GET tanımına hem de REST'in kaynak mantığına aykırı.

API'ye erişimi olan istemci tarafında bir anahtar saklanıyorsa, bu anahtarın nasıl korunması gerektiğini de ayrı ele almak gerekiyor; bu konuyu API anahtarlarına ayırdığımız yazıda işlemiştik. Tarayıcıdan farklı bir alan adına yapılan isteklerde ise CORS kısıtlamaları devreye giriyor; bu mekanizmayı CORS hatasını anlattığımız yazıda ayrıca ele almıştık.

Sık Sorulan Sorular​

REST API nedir, ne işe yarar?
İstemci ve sunucunun HTTP üzerinden, kaynakları standart metodlarla (GET, POST, PUT, DELETE) değiştirdiği bir mimari yaklaşımdır; farklı programlama dilleriyle yazılmış sistemlerin ortak bir arayüz üzerinden konuşmasını sağlar.

REST ile RESTful aynı şey mi?
Günlük kullanımda eş anlamlı görülse de MDN, HTTP servislerinin "RESTful" anılsa bile REST'in tüm mimari kısıtlamalarına uymak zorunda olmadığını belirtiyor.

REST API'de GET isteği veri değiştirebilir mi?
Hayır. RFC 9110'a göre GET, sunucuda değişiklik yapmayan bir metoddur; veri değiştirme işlemleri POST, PUT veya DELETE ile yapılmalıdır.

REST API neden "stateless" olmak zorunda?
HTTP'nin kendisi durum tutmuyor; her istek kendi içinde anlaşılabilir olmalı. Bu, sunucuların yatayda ölçeklenmesini ve isteklerin farklı sunuculara dağıtılmasını kolaylaştırıyor.

REST API yanıtı mutlaka JSON mu olmalı?
Hayır. RFC 9110'un temsil tanımı belirli bir formatı zorunlu kılmıyor; JSON yaygın bir tercih ama aynı kaynak farklı formatlarda da sunulabilir.

Özetle​

REST, MDN'nin tanımıyla dağıtık sistemler için bir mimari kısıtlamalar bütünü; RFC 9110 ise bu mimarinin üzerine oturduğu HTTP metodlarını ve durumsuzluk ilkesini tanımlıyor. "RESTful" etiketi tek başına bir garanti sunmuyor; GET'in veri değiştirmediğini, kaynakların URL'de doğru temsil edildiğini kontrol etmek asıl işi yapıyor.

Kullandığınız API'de GET isteği hiç veri değiştiriyor mu, kontrol ettiniz mi?

Güncelleme: 25 Ağustos 2026.

---