Bir uygulamanın hava durumunu göstermesi, ödeme alması ya da harita üzerinde konum işaretlemesi neredeyse hiçbir zaman o uygulamanın kendi başına yaptığı bir iş değildir. Arka planda başka bir servisle konuşur ve bu konuşmanın dili API'dir. Yazılım dünyasının birbirine bağlanma biçimini anlamak için önce bu arayüzün ne işe yaradığını kavramak gerekir.
API Nedir?
API, açılımıyla Application Programming Interface yani Uygulama Programlama Arayüzü, iki yazılım bileşeninin belirli kurallar çerçevesinde veri alışverişi yapmasını sağlayan bir sözleşmedir. Bir tarafta isteği gönderen istemci, diğer tarafta bu isteği işleyip yanıt üreten sunucu bulunur. Aradaki API ise hangi adrese, nasıl bir formatta ve hangi parametrelerle başvurulacağını tanımlar.
Karşı tarafın kodunu görmeden, veritabanı yapısını bilmeden yalnızca bu arayüzü kullanarak iş yaparsınız. Bu soyutlama sayesinde bir ödeme sağlayıcısı altyapısını tamamen değiştirse bile, sizin entegrasyonunuz API sözleşmesi korunduğu sürece çalışmaya devam eder.
REST Mimarisinin Temel Mantığı
REST, Representational State Transfer kelimelerinin kısaltmasıdır ve aslında bir protokol değil, bir mimari yaklaşımdır. Roy Fielding tarafından 2000 yılında doktora tezinde tanımlanan bu yaklaşım, web'in zaten var olan altyapısını, yani HTTP'yi olabildiğince doğal biçimde kullanmayı önerir.
REST yaklaşımının üzerinde durduğu birkaç ilke vardır:
- Kaynak odaklılık: Her şey bir kaynaktır ve benzersiz bir URL ile adreslenir. Örneğin
/kullanicilar/42ID'si 42 olan kullanıcıyı temsil eder. - Durumsuzluk (stateless): Sunucu iki istek arasında istemciye dair hiçbir bilgi tutmaz. Kimlik doğrulama dahil gereken her şey her istekte yeniden gönderilir.
- Standart metotlar: İşlemler HTTP metotları üzerinden ifade edilir, böylece arayüz öngörülebilir kalır.
- Temsil ayrımı: Aynı kaynak JSON, XML ya da başka bir formatta sunulabilir; veri ile gösterimi birbirinden ayrılır.
HTTP Metotları ve CRUD Eşleşmesi
REST API'lerde bir kaynak üzerinde yapılacak işlem, isteğin HTTP metoduyla belirlenir. Bu metotlar veritabanı dünyasındaki temel işlemlerle, yani CRUD ile büyük ölçüde örtüşür.
| HTTP Metodu | CRUD Karşılığı | Örnek Uç Nokta | Açıklama |
|---|---|---|---|
| GET | Read | GET /urunler/15 | Var olan kaydı getirir, sunucuyu değiştirmez |
| POST | Create | POST /urunler | Yeni kayıt oluşturur |
| PUT | Update | PUT /urunler/15 | Kaydın tamamını günceller |
| PATCH | Update | PATCH /urunler/15 | Kaydın yalnızca belirli alanlarını günceller |
| DELETE | Delete | DELETE /urunler/15 | Kaydı siler |
GET ve DELETE gibi metotların idempotent olması, yani aynı isteği birden çok kez göndermenin sonucu değiştirmemesi, REST'in güvenilirliğini artıran detaylardandır.
Bir REST İsteği Pratikte Nasıl Görünür?
Komut satırından curl ile basit bir istek göndermek, API mantığını anlamanın en doğrudan yoludur. Aşağıdaki örnekte bir API'ye yeni bir kullanıcı kaydı gönderiyoruz:
curl -X POST https://api.ornek.com/v1/kullanicilar \
-H "Content-Type: application/json" \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" \
-d '{
"ad": "Mehmet",
"eposta": "mehmet@ornek.com",
"rol": "editor"
}'
Burada -X POST metodu, -H ile gönderilen başlıklar ve -d ile taşınan JSON gövdesi yer alıyor. Sunucu işlemi başarıyla tamamlarsa genellikle 201 Created durum koduyla, oluşturulan kaynağın temsilini içeren bir yanıt döner.
HTTP Durum Kodları Neden Önemli?
Bir REST API'nin kalitesi, doğru durum kodlarını döndürmesiyle yakından ilişkilidir. İstemci, yanıtın gövdesini okumadan önce durum koduna bakarak işlemin sonucunu anlayabilmelidir.
- 2xx grubu: İşlem başarılı.
200 OK,201 Createdve içerik dönmeyen işlemler için204 No Contentsık kullanılır. - 4xx grubu: Hata istemci tarafında.
400 Bad Request, kimlik doğrulama için401 Unauthorized, yetki için403 Forbiddenve bulunamayan kaynak için404 Not Foundtipiktir. - 5xx grubu: Sorun sunucu tarafında.
500 Internal Server Errorya da geçici aşırı yük durumunda503 Service Unavailablegörülür.
Kimlik Doğrulama ve Güvenlik
Halka açık bir uç noktayı herkesin sınırsızca çağırmasını istemezsiniz. REST API'lerde en yaygın korunma yöntemleri arasında API anahtarları, OAuth 2.0 akışları ve JWT tabanlı erişim jetonları bulunur. Bunlara ek olarak istek sayısını sınırlayan rate limiting uygulamak, kötüye kullanımı ve ani yük artışlarını engellemek açısından kritiktir.
Trafiğin tamamının TLS ile, yani https üzerinden taşınması artık bir tercih değil zorunluluktur. Jetonların URL içinde değil Authorization başlığında taşınması da, bu değerlerin sunucu loglarına ya da tarayıcı geçmişine düşmesini engeller.
Bogahost Önerisi: API trafiğiniz büyüdükçe darboğaz çoğu zaman uygulama kodunda değil, sunucunun kaynaklarında ortaya çıkar. Üzerinde kök erişiminize sahip olduğunuz bir sanal sunucu üzerinde kendi API ortamınızı kurarak Nginx önbellekleme ve PHP-FPM ayarlarını yük profilinize göre özgürce yapılandırabilirsiniz.
API'nin Gerçek Kullanım Alanları
API'ler bugün dijital servislerin görünmez tutkalı durumunda. Sıkça karşılaşılan senaryolardan birkaçı şöyle sıralanabilir:
- Ödeme entegrasyonları: Bir e-ticaret sitesinin sanal POS ya da iyzico gibi sağlayıcılarla konuşması tamamen API üzerinden yürür.
- Mobil uygulamalar: Telefonunuzdaki uygulama, arka uçtaki veriye genellikle bir REST API aracılığıyla erişir.
- Mikroservis mimarileri: Tek bir büyük uygulama yerine, küçük servislerin birbiriyle HTTP üzerinden haberleştiği yapılarda API iç iletişimin omurgasıdır.
- Üçüncü taraf veri: Hava durumu, döviz kuru, harita ve SMS gönderimi gibi hizmetler dışarıdan API ile çekilir.
Düşük ve orta trafikli projelerde bu API'leri barındırmak için iyi yapılandırılmış bir web hosting paketi üzerinde uygulamanızı yayınlamak çoğu durumda fazlasıyla yeterli olur; ölçek arttıkça izole bir sunucuya geçiş mantıklı hale gelir.
REST ve Diğer Yaklaşımlar
REST tek seçenek değildir. İhtiyaç duyulan veri yapısının esnekliği, performans hedefleri ve ekibin alışkanlıkları alternatif yaklaşımları gündeme getirebilir. Aşağıdaki tablo öne çıkan farkları özetliyor.
| Özellik | REST | GraphQL | gRPC |
|---|---|---|---|
| Veri formatı | Genellikle JSON | JSON | Protocol Buffers |
| Taşıma | HTTP/1.1, HTTP/2 | HTTP | HTTP/2 |
| Veri çekme | Sabit uç noktalar | İstemci alanları seçer | Tanımlı servis metotları |
| Tipik kullanım | Genel amaçlı web API | Karmaşık, iç içe veri | Servisler arası iletişim |
Özetle
API, yazılımların ortak bir dilde anlaşmasını sağlayan sözleşmedir; REST ise bu sözleşmeyi web'in kendi araçlarıyla, yani URL'ler ve HTTP metotlarıyla kurmanın sade ve yaygın bir yoludur. Kaynak odaklı düşünmek, doğru metot ve durum kodlarını kullanmak ve güvenliği ihmal etmemek sağlam bir entegrasyonun temelini oluşturur. Bu mantığı bir kez kavradığınızda, karşınıza çıkan hemen her servisin dokümantasyonunu çok daha hızlı okur hale gelirsiniz.
Web Siteniz Hızlansın!
Blogumuzu beğendiniz mi? Web siteniz için yüksek performanslı ve %99.9 uptime garantili hosting paketlerimize göz atın.
Paketleri İncele →