API Nedir? Uygulama Programlama Arayüzü, Örneklerle Basit Rehber

API nedir?

API, yani uygulama programlama arayüzü, bir yazılımın başka bir yazılımla önceden tanımlı kurallar üzerinden konuşmasını sağlayan arayüzdür. Bir programa hangi isteği gönderebileceğinizi, karşılığında nasıl bir yanıt alacağınızı belirler. Böylece iki sistem birbirinin içini bilmeden iş birliği yapar.

Bir benzetmeyle düşünün: Elektrik prizi, cihazınızın santralin nasıl çalıştığını bilmeden elektrik almasını sağlar. API da yazılımlar için böyle bir prizdir. Siz yalnızca fişin şeklini ve izin verilen kullanımı öğrenirsiniz, içeride ne olduğunu merak etmezsiniz.

Bu rehberde API nedir sorusunu sade bir dille açıyoruz. Önce restoran benzetmesiyle temeli kuracak, ardından istek, yanıt, uç nokta, HTTP yöntemleri ve durum kodlarını göreceksiniz. Sonra API türlerini, günlük örnekleri, sınırları ve işletmeler için entegrasyon kontrol listesini bulacaksınız.

Restoran benzetmesi API nedir sorusunu nasıl açıklar?

Bir restorana gittiğinizi düşünün. Aşçılar yemekleri mutfakta hazırlar, ama siz mutfağa girmezsiniz. Önünüzde bir menü vardır ve siz seçtiğiniz yemeği garsona söylersiniz. Garson siparişi mutfağa iletir, yemek hazır olunca size getirir.

Bu sahnede her parçanın yazılım karşılığı vardır:

• Siz, isteği gönderen istemcisiniz (bir mobil uygulama ya da web sitesi).
• Menü, API belgesidir. Hangi isteklerin mümkün olduğunu gösterir.
• Garson, API'nin kendisidir. İsteği alır, doğru yere taşır ve yanıtı getirir.
• Mutfak, veriyi ve iş mantığını barındıran sunucudur.
• Yemek, size dönen yanıttır.

Menüde olmayan bir şeyi isterseniz garson bunu karşılayamaz. Aynı şekilde API de yalnızca tanımlı isteklere cevap verir. Bu kısıt aslında bir güvencedir, çünkü mutfağın içine herkes giremez.

API nedir sorusunun teknik karşılığı olan istek ve yanıt nasıl işler?

Bir API çağrısı iki parçadan oluşur: istek ve yanıt. İstemci isteği gönderir, sunucu yanıtı döndürür. Bu döngü saniyenin çok küçük bir bölümünde gerçekleşebilir ve kullanıcı çoğu zaman bunu fark etmez.

İstek genellikle şu bilgileri taşır:

• Hedef adres, yani hangi kaynağa ulaşılmak istendiği.
• Bir yöntem, yani ne yapılmak istendiği (okumak, eklemek, silmek gibi).
• Başlıklar, yani isteğin kimden geldiği ve hangi biçimi beklediği gibi ek bilgiler.
• Gerekirse bir gövde, yani gönderilen verinin kendisi.

Yanıt ise bir durum kodu, başlıklar ve çoğu zaman bir veri gövdesi içerir. Örneğin bir hava durumu API'sine şehir adını gönderirsiniz. Karşılığında sıcaklık ve nem bilgisini alırsınız.

Bu kuralların tamamı HTTP protokolüne dayanır. IETF'in RFC 9110 belgesi HTTP'nin anlamını tanımlar. Mozilla'nın MDN HTTP belgeleri ise aynı konuyu uygulamalı biçimde anlatır.

Bir API çağrısı baştan sona nasıl ilerler?

Somut bir örnekle gidelim. Bir müşteri, sipariş sayfasında kargosunun nerede olduğunu görmek istiyor. Bu sırada arka planda şu adımlar gerçekleşir:

1. Müşteri sayfayı açar ve tarayıcı sizin sunucunuza gider.
2. Sunucunuz, kargo firmasının API adresine bir GET isteği hazırlar ve içine takip numarasıyla anahtarınızı koyar.
3. Kargo firmasının sunucusu anahtarı doğrular ve takip numarasını kendi sisteminde arar.
4. Kayıt bulunursa 200 koduyla birlikte gönderi durumunu JSON olarak döndürür.
5. Sunucunuz bu veriyi okur ve müşterinin göreceği sayfaya yerleştirir.
6. Müşteri hiçbir şey fark etmeden "Dağıtıma çıktı" gibi bir durum görür.

Bu zincirde API nedir sorusunun cevabı net görünür: İki sistem arasındaki sözleşme. Siz kargo firmasının sisteminde ne olduğunu bilmezsiniz, o da sizin sayfanızı bilmez. Yalnızca sözleşmeye uygun mesajlaşırsınız.

Takip numarası yanlışsa 404, anahtar geçersizse 401, firma sunucusu çökmüşse 500 gibi kodlar döner. Bu nedenle iyi bir sistem her durum için müşteriye anlamlı bir mesaj hazırlar.

Uç nokta (endpoint) nedir ve bir API adresini nasıl okursunuz?

Uç nokta, API'nin belirli bir kaynağa açılan adresidir. Bir kapıya benzer: Her kapı farklı bir odaya çıkar. Örneğin siparişler için bir adres, müşteriler için başka bir adres bulunabilir.

Bir adres genellikle üç parçadan oluşur. Önce alan adı gelir, yani example.com gibi sunucunun adı. Ardından yol gelir, yani hangi kaynağın istendiği. Son olarak isteğe bağlı parametreler gelir, yani sonucu daraltan filtreler.

Kaynak adları çoğu zaman çoğul isimlerdir. Bu nedenle bir adrese bakınca ne döneceğini tahmin edebilirsiniz. Müşteri listesi için müşteriler, tek bir müşteri için müşteriler ve bir kimlik numarası gibi.

İyi düşünülmüş bir API'de adresler tahmin edilebilir olur. Dolayısıyla belgeyi her seferinde açmak zorunda kalmazsınız. Özensiz bir API'de ise aynı iş için üç farklı adres bulabilirsiniz, bu da hata riskini artırır.

HTTP yöntemleri API'de ne anlama gelir?

Yöntem, isteğin niyetini bildirir. Web API'lerinde dört yöntem çok yaygındır ve gündelik hayattaki bir arşiv dolabına benzetilebilir. Dolaptan dosya almak, dosya eklemek, dosyayı değiştirmek ve dosyayı atmak dört ayrı eylemdir.

Bu eşleşme bir kuraldan çok bir gelenektir, ama sektörde çoğu ekip bu geleneğe uyar. Ayrıca GET gibi yan etkisiz yöntemler veriyi bozmamalıdır. Yani aynı isteği birçok kez göndermek veriyi bozmamalıdır.

Aynı isteğin tekrarında sonucun değişmemesi özelliğine idempotentlik denir. Ayrıntıyı idempotency nedir yazımızda anlattık. Yöntemlerin resmi tanımını da MDN HTTP yöntemleri sayfasında bulabilirsiniz.

Durum kodları API'nin cevabını nasıl anlatır?

Her yanıt üç haneli bir durum koduyla başlar. Bu kod, işin nasıl sonuçlandığını tek bakışta söyler. Kodlar yüzlük gruplar hâlinde gelir ve ilk hane sonucun türünü gösterir.

Burada kritik ayrım şudur: 4xx kodları genellikle isteği gönderenin düzeltmesi gereken bir şeye işaret eder. 5xx kodları ise sorunun sunucuda olduğunu söyler. Dolayısıyla hata ayıklarken önce ilk hanenize bakın.

Kodların resmi listesi MDN durum kodları sayfasında durur. Yaygın iki hatanın ayrıntısı için 401 Unauthorized hatası ve 500 Internal Server Error yazılarımıza bakabilirsiniz.

API veriyi hangi biçimde taşır?

Web API'leri veriyi metin olarak taşır ve en yaygın biçim JSON'dur (JavaScript Object Notation). JSON, anahtar ve değer çiftlerinden oluşan okunaklı bir yapıdır. İnsan gözüyle okunabilir, makineler için de işlemesi kolaydır.

Örneğin bir müşteri kaydı; ad, e-posta ve şehir alanlarından oluşan küçük bir metin olarak gelir. Her alanın adı bellidir ve değerler yanında durur. Bu yapı sayesinde alıcı taraf hangi bilginin nerede olduğunu bilir.

Bazı eski ya da kurumsal sistemler XML kullanır. Dosya aktarımı gibi işlerde ikili (binary) biçimler de çıkabilir. Ancak yeni başlayan biri için JSON'u öğrenmek yeterli bir başlangıçtır.

Verinin biçimini, başlıklardaki içerik türü bilgisi söyler. Böylece alıcı gelen metni nasıl okuyacağını bilir. Bu küçük ayrıntı, iki sistemin sorunsuz anlaşmasında şaşırtıcı derecede önemlidir.

Ön yüz ve arka yüz API ile nasıl ilişkilenir?

Bir web uygulamasında iki katman vardır: Kullanıcının gördüğü ön yüz ve verinin işlendiği arka yüz. API, bu iki katmanın arasındaki köprüdür. Ön yüz bir ekran çizerken ihtiyaç duyduğu veriyi API'den ister.

Bu ayrımın büyük bir faydası var. Aynı API'yi web sitesi, mobil uygulama ve iş ortağı sistemi birlikte kullanabilir. Dolayısıyla veriyi bir kez doğru üretirsiniz ve her yerde aynı sonucu görürsünüz.

Ön yüz tarafını front-end nedir yazımızda, arka yüz tarafını ise yukarıda andığımız back-end rehberinde anlattık. Ekipler çoğu zaman iki tarafı API sözleşmesi üzerinden paralel geliştirir. Böylece biri bitmeden diğeri beklemez.

API anahtarı ve kimlik doğrulama neden gerekir?

Her API herkese açık değildir. Sunucu, isteği gönderenin kim olduğunu ve neye yetkisi olduğunu bilmek ister. Bunun iki ayrı sorusu vardır: Kimlik doğrulama sizin kim olduğunuzu, yetkilendirme ise neye erişebileceğinizi belirler.

En basit yöntem API anahtarıdır. Bu, uzun ve tahmin edilemez bir metindir ve her istekle birlikte yola çıkar. Anahtar bir bina giriş kartına benzer: Kapıyı açar, ama hangi odalara gireceğiniz ayrıca tanımlıdır.

Daha esnek senaryolarda belirteç (token) tabanlı yöntemler devreye girer:

• OAuth 2.0, bir kullanıcının şifresini paylaşmadan başka bir uygulamaya sınırlı erişim vermesini sağlar.
• JWT, kimlik bilgisini imzalı bir belirteç içinde taşır.
• Oturum çerezleri, tarayıcı tabanlı uygulamalarda yaygındır.

Anahtarı asla herkese açık bir sayfaya ya da mobil uygulama paketine koymayın. Sızan bir anahtar, sizin adınıza istek göndermek isteyen herkese kapı açar. Ayrıca anahtarları düzenli aralıklarla yenilemek iyi bir alışkanlıktır.

API türleri nelerdir ve nasıl ayrışır?

API kelimesi tek bir teknolojiyi değil, geniş bir kavramı anlatır. Günlük konuşmada çoğu zaman web API'lerini kastederiz, ama kütüphane ve işletim sistemi API'leri de vardır. Bu yüzden önce hangi türden söz edildiğini netleştirmek yararlıdır.

Bu yazıda ağırlık web API'lerinde, çünkü işletmelerin en çok karşılaştığı tür bu. Yine de kütüphane API'sinin de aynı mantığı izlediğini bilmek faydalıdır: Hazır bir işlevi, tanımlı kurallarla çağırırsınız.

REST API nedir ve neden bu kadar yaygındır?

REST, web API'leri tasarlamak için kullanılan bir mimari yaklaşımdır. Kaynakları adreslerle tanımlar, işlemleri HTTP yöntemleriyle yapar ve her isteği bağımsız tutar. Yani sunucu bir önceki isteğinizi hatırlamak zorunda kalmaz.

Yaygın olmasının birkaç nedeni var. İlk olarak HTTP zaten her yerde çalışır, bu yüzden ek bir araç gerekmez. İkinci olarak adresler ve yöntemler okunaklıdır, yeni biri hızla kavrar. Üçüncü olarak her dilde ve her platformda istemci yazmak kolaydır.

REST bir standart değil, bir tasarım felsefesidir. Dolayısıyla iki REST API birbirinden oldukça farklı görünebilir. Bu esneklik avantajdır, ama tutarsızlık da üretebilir.

Bir API'nin ne sunduğunu sunucu tarafında görmek için back-end nedir yazımıza göz atın. Orada API'nin arkasındaki katmanları anlatıyoruz.

GraphQL ve gRPC ne zaman akla gelir?

REST her zaman ideal olmayabilir. Bir mobil ekran yalnızca üç alana ihtiyaç duyuyorsa, REST yanıtının on alan taşıması gereksiz veri trafiği yaratır. GraphQL bu durumda devreye girer: İstemci tam olarak hangi alanları istediğini söyler ve yalnızca onları alır.

GraphQL'in artıları ve eksilerini GraphQL nedir ve REST farkı yazımızda ayrıntılı işledik. Kısacası, birden çok istemcinin veri ihtiyacı farklıysa GraphQL işinize yarar.

gRPC ise servislerin kendi aralarında hızlı konuşması için tercih edilir. Veriyi ikili biçimde taşıdığı için daha az yer kaplar. Bu yüzden büyük mimarilerde, özellikle mikroservis mimarisi kullanan ekiplerde yaygındır.

Yeni başlayan biri için doğru sıra şudur: Önce REST'i iyi öğrenin. Sonra ihtiyaç doğduğunda diğer ikisine geçin.

Açık, özel ve iş ortağı API arasındaki fark nedir?

API'leri erişim kapsamına göre de gruplayabilirsiniz. Bu ayrım, kimin hangi veriye hangi koşulla ulaşabileceğini belirler. Dolayısıyla bir API'yi seçerken ya da yayınlarken ilk soracağınız sorulardan biridir.

Özel API'ler çoğu zaman en kalabalık gruptur, ama dışarıya açılmaz. Bir şirketin mobil uygulaması da kendi sunucusuyla genellikle özel bir API üzerinden konuşur.

Açık bir API sunmak, ürününüz için yeni dağıtım kanalı yaratabilir. Ancak sorumluluk da getirir: Belge, destek, sürümleme ve güvenlik işi artar.

Günlük hayatta API nerede çalışır?

API'yi fark etmeden her gün kullanırsınız. Aşağıdaki örnek senaryolar aynı mantığı farklı yüzlerle gösterir:

• Haritayı siteye gömme: Bir işletme sitesinde şubenin konumu bir harita olarak çıkar. Site, harita servisinin API'sine konum bilgisini gönderir ve görüntüyü geri alır.
• Ödeme: Müşteri kartla ödeme yaptığında site, ödeme sağlayıcının API'sine tutarı ve sipariş bilgisini iletir. Sağlayıcı sonucu bildirir, site siparişi onaylar.
• Kargo takibi: Sipariş sayfasında gördüğünüz gönderi durumu, kargo firmasının API'sinden gelir. Siz sayfayı açtığınızda güncel bilgi gelir.
• Hava durumu: Telefonunuzdaki uygulama, konumunuzu bir veri servisine sorar ve sıcaklık bilgisini ekranda gösterir.

Bu örneklerin hepsi kurgusal senaryodur, ama gerçek sistemlerin çalışma biçimini yansıtır. Ortak nokta şudur: Siz kendi ürününüzü yazarken her işi sıfırdan yapmazsınız. Uzman bir servisin işini, API üzerinden ödünç alırsınız.

Ödeme tarafını seçerken sanal pos ve online ödeme altyapısı seçimi yazımız yol gösterebilir.

Rate limit nedir ve API neden istek sayısını sınırlar?

Rate limit, belirli bir sürede gönderebileceğiniz istek sayısına konan sınırdır. Sınırı aşarsanız sunucu genellikle 429 koduyla yanıt verir ve bir süre beklemenizi ister. Bu, bir restoranda mutfağın aynı anda yalnızca belirli sayıda siparişi alabilmesine benzer.

Sınırın birkaç nedeni vardır. İlk olarak sunucuyu aşırı yükten korur. İkinci olarak kötü niyetli ya da hatalı bir istemcinin herkesin deneyimini bozmasını engeller. Üçüncü olarak kaynakların adil paylaşılmasını sağlar.

Geliştirici olarak şu alışkanlıkları edinmek faydalıdır:

• Aynı veriyi tekrar tekrar istemek yerine yanıtı bir süre saklayın.
• Hata aldığınızda anında yeniden denemeyin, her denemede biraz daha bekleyin.
• Belgedeki sınır değerlerini okuyun, çünkü bu değerler servise göre değişir ve güncel hâli yalnızca sağlayıcının belgesindedir.

Bu kavramda rakam vermiyoruz, çünkü kota ve limitler sağlayıcıdan sağlayıcıya değişir. Güncel değeri her zaman resmi belgeden kontrol edin.

API sürümleme neden önemlidir?

Bir API yayına çıktıktan sonra onu kullanan uygulamalar ona güvenir. Alan adını değiştirirseniz ya da yanıt biçimini bozarsanız bu uygulamalar çalışmayı bırakabilir. Sürümleme, bu riski yönetmenin yoludur.

Mantık basittir. Köklü bir değişiklik gerektiğinde yeni bir sürüm yayınlarsınız ve eskisini bir süre çalışır tutarsınız. Böylece istemciler yeni sürüme kendi hızlarında geçer. Sürüm bilgisi genellikle adreste ya da başlıkta yer alır.

İyi bir sürümleme politikası üç şeyi içerir:

1. Hangi değişikliklerin geriye uyumlu, hangilerinin uyumsuz olduğunu tanımlayın.
2. Eski sürümü kapatmadan önce yeterli süre ve açık duyuru verin.
3. Değişiklik kayıtlarını belgede herkese açık tutun.

Kısacası sürümleme, sözünüzün güvencesidir. API'yi kullanan herkes, sabah uyandığında sistemlerinin bozulmayacağını bilmek ister.

API belgesi ve OpenAPI nedir?

API belgesi, API'nin menüsüdür. Hangi adreslerin bulunduğunu, hangi yöntemlerin kullanılabileceğini, hangi alanların zorunlu olduğunu ve hangi hataların dönebileceğini anlatır. İyi bir belge, API'nin yarısı kadar değerlidir.

OpenAPI, REST API'lerini makine tarafından okunabilir biçimde tanımlamak için kullanılan bir şartnamedir. Böylece belge yalnızca insanlar için bir metin olmaktan çıkar. Araçlar bu tanımdan etkileşimli belge, test ve hatta istemci kodu üretebilir.

Şartnamenin resmi kaynağı OpenAPI Initiative sitesidir. Bir API ile çalışacaksanız, OpenAPI tanımı sunup sunmadığına bakmak zaman kazandırır.

Yapay zeka tarafında da benzer bir ihtiyaç vardır: Modelin hangi araçları çağırabileceğini tanımlamak gerekir. Bu konuyu function calling nedir yazısında anlattık.

API, SDK, webhook ve entegrasyon birbirinden nasıl farklıdır?

Bu dört terim sık karışır, çünkü hepsi sistemleri birbirine bağlama işiyle ilgilidir. Ancak her birinin rolü farklıdır. Aşağıdaki tablo, farkı tek bakışta gösterir.

Burada önemli bir fark var: API'de siz sorarsınız, webhook'ta ise karşı sistem size söyler. Bu yüzden sipariş durumunu sürekli sormak yerine, durum değişince haber alırsınız. Böylece gereksiz istekler azalır.

Entegrasyon ise en geniş kavramdır. Bir entegrasyon API, webhook ve veri dönüşümünün hepsini içerebilir. Kurumsal siteler için örnekleri CRM, ERP ve chatbot entegrasyonları yazısında bulabilirsiniz.

API kullanırken hangi riskler ortaya çıkar?

API'ler iş yükünü hafifletir, ama yeni riskler de getirir. Bu riskleri baştan bilmek, ileride çıkabilecek sürprizleri azaltır.

• Bağımlılık: Kritik bir iş akışı tek bir dış servise bağlıysa, o servis aksadığında sizin işiniz de aksar.
• Güvenlik: Sızan anahtarlar, aşırı geniş yetkiler ve korumasız adresler veri sızıntısına yol açabilir.
• Değişiklik: Sağlayıcı bir alanı kaldırırsa ya da davranışı değiştirirse sizin kodunuz bozulabilir.
• Veri gizliliği: Kişisel veriyi dış bir servise gönderiyorsanız, bu veri akışının hukuki ve sözleşmesel koşullarını bilmeniz gerekir.
• Maliyet: İstek başına ücretlendirme yapan servislerde kontrolsüz kullanım beklenmedik gider yaratır.

Bu risklerin her biri için bir önlem vardır. Örneğin zaman aşımı ve yeniden deneme mantığı eklersiniz, yetkileri en düşük düzeyde tutarsınız ve kullanımı izlersiniz. Ayrıca bağlantının güvenli olup olmadığını SSL sorgulama aracımızla kontrol edebilirsiniz.

Kişisel veri içeren entegrasyonlarda hukuki danışmanlık almanız gerekir. Bu yazı hukuki danışmanlık değildir.

API ile geliştirmeye nasıl başlarsınız?

API'yi anlamanın en iyi yolu, küçük bir isteği kendi gözünüzle görmektir. Kod yazmadan bile başlayabilirsiniz, çünkü tarayıcı adres çubuğu basit bir okuma isteği gönderebilir. Adım adım ilerlemek için şu sırayı izleyin:

1. Basit ve açık bir API seçin. Anahtar gerektirmeyen bir örnek veri servisi idealdir.
2. Belgesini okuyun ve bir uç nokta bulun.
3. İsteği bir araçla ya da tarayıcıyla gönderin ve yanıtı inceleyin.
4. Durum kodunu ve veri alanlarını not edin.
5. Hatalı bir istek gönderip hata yanıtının nasıl göründüğünü görün.
6. Ardından kendi programınızdan aynı isteği tekrarlayın.

Bu sırayı izlerseniz, her adımda neyin değiştiğini net görürsünüz. Programlamayı yeni öğreniyorsanız, ilk hedefiniz tek bir isteği çalıştırmak olsun. Karmaşık kimlik doğrulamaya sonra geçersiniz.

Yapay zeka servislerini deneyecekseniz, aynı mantığın orada da geçerli olduğunu göreceksiniz. Başlangıç için OpenAI API rehberi iyi bir örnektir.

İşletme için API entegrasyonu kontrol listesi nasıl olmalı?

Bir işletme olarak bir API'yi ürününüze bağlamadan önce teknik ve iş tarafını birlikte tartmanız gerekir. Aşağıdaki liste, karar öncesi için pratik bir çerçeve sunar:

1. Amacı yazın: Bu API hangi iş sorununu çözecek ve başarıyı nasıl ölçeceksiniz?
2. Belgeyi inceleyin: Güncel mi, örnekler var mı, hata yanıtlarını anlatıyor mu?
3. Kimlik doğrulama yöntemini öğrenin ve anahtarların nerede saklanacağına karar verin.
4. Kullanım sınırlarını ve ücretlendirme mantığını sağlayıcının resmi sayfasından kontrol edin.
5. Sürümleme ve eski sürüm kapatma politikasını sorun.
6. Kişisel veri akışı varsa gizlilik ve sözleşme koşullarını inceleyin.
7. Hata durumunu planlayın: Servis çalışmazsa kullanıcı ne görecek?
8. Test ortamı (sandbox) olup olmadığını öğrenin ve canlıya geçmeden önce orada deneyin.
9. İzleme kurun: Hata oranını ve gecikmeyi takip edin.
10. Sağlayıcıya bağımlılığınızı değerlendirin ve gerekirse yedek bir plan hazırlayın.

Bu listeyi proje başında doldurmak, ileride gerekecek maliyetli değişiklikleri azaltır. Özel bir entegrasyon ya da yeni bir yazılım ihtiyacınız varsa, özel yazılım geliştirme hizmet sayfamızdan bize ulaşabilirsiniz.

API hakkında sık yapılan yanlışlar nelerdir?

API konusunda birkaç yanlış anlama sürekli tekrar eder. Bunları baştan düzeltmek öğrenmeyi hızlandırır.

• "API bir veritabanıdır." Hayır, API bir kapıdır. Arkasında bir veritabanı olabilir, ama API'nin kendisi veri saklamaz.
• "API ile web sitesi aynı şeydir." Hayır, web sitesi insana görsel sunar. API ise yazılıma veri sunar.
• "API her zaman ücretsizdir." Hayır, bazıları ücretsiz, bazıları kullanıma göre ücretlidir. Güncel koşulu sağlayıcıdan kontrol edin.
• "API anahtarı bir şifredir, herkesle paylaşılabilir." Hayır, anahtar özeldir ve gizli tutulmalıdır.
• "REST tek API türüdür." Hayır, GraphQL, gRPC ve kütüphane API'leri de vardır.

Bu yanlışların çoğu, API'nin soyut olmasından doğar. Kullanıcı arayüzü olmadığı için insanlar onu somut bir şeye benzetmekte güçlük çeker. Restoran ve priz benzetmeleri tam bu boşluğu doldurur.

Sonuç olarak API nedir sorusunun kısa özeti nedir?

API, yazılımların birbiriyle tanımlı kurallar üzerinden konuşmasını sağlayan sözleşmedir. İstemci bir istek gönderir, sunucu bir yanıt döndürür. Bu yanıt bir durum koduyla gelir ve çoğunlukla JSON biçiminde veri taşır.

Hatırlamanız gereken noktalar şunlardır: Uç nokta adrestir, yöntem niyettir, durum kodu sonuçtur. Anahtar ve belirteç kimlik doğrular, rate limit kaynağı korur, sürümleme uyumu sağlar. Web, kütüphane ve işletim sistemi düzeyinde farklı API türleri vardır.

Bir işletme olarak API'leri akıllıca kullanmak, her şeyi sıfırdan yazmaktan çok daha hızlı ve güvenlidir. Yeter ki belgeyi okuyun, riskleri tartın ve izlemeyi ihmal etmeyin. Komşu konular için OAuth 2.0 nedir ve IaaS, PaaS ve SaaS nedir yazılarımıza göz atabilirsiniz.

Teknik ayrıntılar zamanla değişir, ama API'nin temel mantığı kalıcıdır. Bu nedenle ürün sürümlerine ve sayılara değil, kavrama odaklanmanız uzun vadede en doğru yatırımdır.