Bir e-ticaret sitesinde ödeme yaptığınızda, kargo durumunu görüntülediğinizde veya bir uygulamada harita açtığınızda farklı yazılım sistemleri arka planda birbiriyle iletişim kurar. Ödeme sistemi bankayla, mağaza kargo firmasıyla, mobil uygulama ise merkezi veri tabanıyla veri alışverişi yapar. Bu iletişimin önemli bölümü API üzerinden gerçekleşir.
Peki API nedir, nasıl çalışır ve işletmeler neden API entegrasyonuna ihtiyaç duyar? API yalnızca yazılımcıların kullandığı teknik bir araç değildir; farklı sistemlerdeki verilerin otomatik akmasını ve dijital hizmetlerin birlikte çalışmasını sağlayan temel bir yazılım bileşenidir.
Bu rehberde API’nin çalışma mantığını; istemci, sunucu, endpoint, HTTP metotları ve durum kodları üzerinden açıklayacağız. REST, SOAP ve GraphQL yaklaşımlarını karşılaştıracak; API ile webhook arasındaki farkı, güvenlik gereksinimlerini ve başarılı entegrasyon sürecini ele alacağız. Ayrıca EKKASOFT ile özel API ve sistem entegrasyonlarının nasıl planlanabileceğini inceleyeceğiz.
Güncellik notu: Bu yazı 4 Ağustos 2026 tarihinde hazırlanmıştır. API standartları, sağlayıcı belgeleri ve güvenlik uygulamaları değişebildiği için entegrasyon öncesinde ilgili servisin güncel teknik dokümantasyonu doğrulanmalıdır.
API Nedir?
API, “Application Programming Interface” yani “Uygulama Programlama Arayüzü” ifadesinin kısaltmasıdır. İki veya daha fazla yazılımın hangi kurallarla iletişim kuracağını tanımlar.
Bir API şu sorulara cevap verir:
- Hangi işlemler yapılabilir?
- İstek hangi adrese gönderilmelidir?
- Hangi veri alanları zorunludur?
- Kullanıcı veya uygulama nasıl doğrulanır?
- Başarılı ya da başarısız işlem nasıl bildirilir?
- Ne kadar sıklıkla istek gönderilebilir?
API’yi restoran benzetmesiyle açıklayabiliriz. Müşteri siparişini garsona iletir; garson mutfağın kabul ettiği düzende siparişi aktarır ve hazırlanan sonucu müşteriye getirir. Müşteri mutfağın iç işleyişini bilmek zorunda değildir. Benzer biçimde bir uygulama, başka sistemin veri tabanına doğrudan bağlanmak yerine o sistemin sunduğu API kurallarıyla işlem yapar.
Bu benzetmede:
- Müşteri, isteği yapan uygulamadır
- Menü, kullanılabilecek API işlemlerini gösteren dokümantasyondur.
- Garson, isteği taşıyan API arayüzüdür.
- Mutfak, işlemi gerçekleştiren sunucu ve iş kurallarıdır.
- Hazırlanan yemek, API yanıtıdır.
API, karşı sistemin iç kodunu açmadan kontrollü bir iletişim noktası sunar. Böylece iki uygulama farklı programlama dilleriyle geliştirilmiş olsa bile ortak veri formatı ve protokol üzerinden çalışabilir.
API Ne İşe Yarar?
API’lerin temel amacı sistemler arasında güvenli ve standartlaştırılmış veri alışverişi sağlamaktır. İşletmeler açısından başlıca kullanım alanları şunlardır:
- Manuel veri girişini azaltmak
- Farklı sistemlerdeki kayıtları senkronize etmek
- Mevcut bir hizmeti başka uygulamada kullanmak
- Web, mobil ve masaüstü uygulamalarını aynı backend’e bağlamak
- İş ortaklarına kontrollü veri ve işlem erişimi vermek
- Tekrarlanan süreçleri otomatikleştirmek
- Yeni satış ve hizmet kanalları oluşturmak
Örneğin e-ticaret sitesi siparişi aldığında API üzerinden ödeme sonucunu doğrulayabilir, ERP’de satış kaydı açabilir, stok miktarını güncelleyebilir ve kargo firmasından gönderi kodu oluşturabilir. API olmadığında personel bu bilgileri farklı panellere elle girmek zorunda kalabilir.
API Nasıl Çalışır?
Web API’leri çoğunlukla istek–yanıt modeliyle çalışır. Bir istemci belirli adrese istek gönderir; sunucu isteği doğrular, gerekli işlemi yapar ve sonuç döndürür.
Temel akış şöyledir:
- İstemci yapmak istediği işlemi ve ilgili veriyi hazırlar.
- İstek HTTPS üzerinden API endpoint’ine gönderilir.
- API kimlik doğrulama ve yetki kontrolü yapar.
- Gönderilen veri doğrulanır.
- İş kuralları çalıştırılır; gerekiyorsa veri tabanı veya başka servis çağrılır.
- Sonuç bir durum kodu ve yanıt gövdesiyle istemciye iletilir.
- İstemci başarılı sonucu işler veya hata senaryosunu yönetir.
Bir kargo kaydı oluşturma isteğini düşünelim. E-ticaret yazılımı sipariş numarası, teslimat adresi ve paket bilgilerini kargo API’sine gönderir. Kargo sistemi yetkiyi ve adresi kontrol eder, gönderi kaydı oluşturur ve takip numarasını döndürür. E-ticaret yazılımı bu numarayı siparişe kaydeder ve müşteriye gösterir.
API’nin Temel Bileşenleri
İstemci ve sunucu
İstemci, API’den veri veya işlem talep eden uygulamadır. Web sitesi, mobil uygulama, ERP ya da başka bir backend istemci olabilir.
Sunucu, API isteğini karşılayan, iş kurallarını uygulayan ve yanıt üreten sistemdir. Aynı uygulama bir entegrasyonda istemci, başka bir entegrasyonda sunucu rolünü üstlenebilir.
Endpoint nedir?
Endpoint, API’de belirli bir kaynak veya işleme ulaşmak için kullanılan adrestir. Örneğin:
https://api.ornek.com/v1/orders/1250
Bu adreste orders sipariş kaynağını, 1250 ise belirli siparişi temsil edebilir. Aynı URL’ye farklı HTTP metotlarıyla gönderilen istekler farklı işlemler ifade edebilir.
Request nedir?
Request, istemcinin API’ye gönderdiği istektir. Genellikle şu bölümleri içerir:
- URL veya endpoint
- HTTP metodu
- Header bilgileri
- Kimlik doğrulama bilgisi
- Parametreler
- Gerekliyse veri gövdesi
Response nedir?
Response, API’nin isteğe verdiği yanıttır. Yanıtta HTTP durum kodu, header bilgileri ve çoğunlukla JSON veya XML biçiminde veri bulunur.
Örnek bir JSON yanıtı şöyledir:
{ "order_id": 1250, "status": "shipped", "tracking_number": "TRK-908172" }
HTTP Metotları Ne Anlama Gelir?
Web API’lerinde HTTP metotları isteğin amacını belirtir. MDN, her HTTP metodunun kendine özgü anlamı bulunduğunu ve bazı metotların güvenli, idempotent veya önbelleğe alınabilir olabileceğini açıklar.
| Metot | Genel amaç | Örnek |
|---|---|---|
| GET | Veri okumak | Sipariş detayını getirmek |
| POST | Yeni işlem veya kayıt oluşturmak | Yeni sipariş oluşturmak |
| PUT | Kaynağı bütünüyle oluşturmak veya değiştirmek | Müşteri kaydını tüm alanlarıyla yenilemek |
| PATCH | Kaynağın belirli alanlarını güncellemek | Sipariş durumunu değiştirmek |
| DELETE | Kaynağı silmek | Taslak kaydı kaldırmak |
GET isteğinin sunucudaki veriyi değiştirmemesi beklenir. PUT ise genellikle idempotent tasarlanır; aynı isteğin birden fazla kez gönderilmesi ilk uygulamadan sonra ek etki oluşturmamalıdır. Bununla birlikte gerçek davranış API sözleşmesinde açıkça belirtilmelidir.
Ödeme ve sipariş gibi işlemlerde ağ kesintisi nedeniyle aynı istek tekrar gönderilebilir. Mükerrer tahsilat veya kayıt oluşmasını engellemek için idempotency key gibi mekanizmalar kullanılabilir.
HTTP Durum Kodları
API yanıtındaki durum kodu işlemin genel sonucunu gösterir. HTTP kodları beş gruba ayrılır:
- 100–199: Bilgilendirme
- 200–299: Başarılı işlem
- 300–399: Yönlendirme
- 400–499: İstemci kaynaklı hata
- 500–599: Sunucu kaynaklı hata
API’lerde sık kullanılan bazı kodlar şunlardır:
| Kod | Anlamı | Örnek durum |
|---|---|---|
| 200 | İşlem başarılı | Kayıt getirildi veya güncellendi |
| 201 | Kaynak oluşturuldu | Yeni sipariş açıldı |
| 204 | Başarılı, içerik yok | Silme işlemi tamamlandı |
| 400 | Geçersiz istek | Zorunlu alan eksik |
| 401 | Kimlik doğrulama gerekli veya geçersiz | Token hatalı |
| 403 | İşlem için yetki yok | Kullanıcı kaynağa erişemez |
| 404 | Kaynak bulunamadı | Sipariş numarası yok |
| 409 | Çakışma | Aynı kayıt zaten mevcut |
| 422 | Veri iş kuralına uygun değil | Stok miktarı yetersiz |
| 429 | Çok fazla istek | Rate limit aşıldı |
| 500 | Sunucu hatası | Beklenmeyen uygulama hatası |
| 503 | Hizmet geçici olarak kullanılamıyor | Bakım veya kapasite sorunu |
Yalnızca durum koduna değil yanıt gövdesindeki hata kodu ve açıklamaya da bakılmalıdır. İstemci, her hatayı körlemesine tekrar etmemeli; yalnızca geçici hatalarda kontrollü bekleme ve tekrar stratejisi uygulamalıdır.
JSON Nedir ve API’lerde Neden Kullanılır?
JSON, veriyi anahtar–değer yapısıyla ifade eden metin tabanlı bir formattır. İnsanlar tarafından okunabilir, birçok programlama dilinde kolayca işlenebilir ve XML’e göre çoğu kullanımda daha sade olduğu için web API’lerinde yaygın biçimde kullanılır.
Örnek bir API isteği:
{ "customer_id": 840, "items": [ { "product_id": 52, "quantity": 2 } ], "currency": "TRY" }
JSON yalnızca veri formatıdır; API’nin güvenli veya REST uyumlu olduğunu göstermez. Alanların anlamı, veri türleri ve zorunlulukları dokümantasyonda tanımlanmalıdır.
API Türleri: Kimler Erişebilir?
API’ler erişim kapsamına göre sınıflandırılabilir.
Public API
Belirli koşullarla dış geliştiricilere açılan API’dir. Herkese açık dokümantasyonu olabilir; fakat bu, kimlik doğrulama veya kullanım sınırı bulunmadığı anlamına gelmez.
Partner API
Yalnızca anlaşmalı iş ortaklarının kullanabildiği API’dir. Ödeme kuruluşu, bayi veya lojistik iş ortağı entegrasyonları bu yapıda olabilir.
Private API
Kurumun kendi uygulamaları ve ekipleri arasında kullanılan API’dir. İnternete açık olmaması güvenlik kontrolüne ihtiyaç duymadığı anlamına gelmez; kimlik doğrulama ve yetkilendirme yine gereklidir.
Composite API
Bir iş sonucunu üretmek için birden fazla işlemi tek çağrıda veya tanımlı akışta birleştiren API yaklaşımıdır. Özellikle çok sayıda küçük çağrının ağ maliyetini azaltmak için kullanılabilir; hata ve geri alma senaryoları dikkatle tasarlanmalıdır.
REST API Nedir?
REST, “Representational State Transfer” ifadesinin kısaltmasıdır. Dağıtık sistemler için bir mimari yaklaşımıdır; tek başına protokol değildir. REST API’leri çoğunlukla HTTP üzerinde çalışır ve kaynakları URL’lerle temsil eder.
REST yaklaşımında:
- Kaynaklar anlamlı URL’lerle tanımlanır.
- HTTP metotları amaçlarına uygun kullanılır.
- Her istek gerekli bağlamı taşıyacak şekilde durumsuz tasarlanır.
- Standart durum kodları kullanılır.
- Yanıtlar uygun olduğunda önbelleğe alınabilir.
- İstemci ile sunucu sorumlulukları ayrılır.
Örneğin /orders/1250 adresi belirli siparişi temsil edebilir. GET siparişi getirirken PATCH belirli alanlarını güncelleyebilir.
Her JSON döndüren HTTP servisi tam anlamıyla REST değildir. Buna rağmen sektörde “REST API” ifadesi, HTTP metotları ve kaynak tabanlı endpoint’lerle çalışan web API’leri için yaygın biçimde kullanılır.
SOAP API Nedir?
SOAP, yapılandırılmış bilgi alışverişi için XML teknolojilerini kullanan bir mesajlaşma protokolüdür. W3C’nin SOAP 1.2 standardı, merkezi olmayan dağıtık ortamlarda mesaj değişimi için genişletilebilir bir çerçeve tanımlar.
SOAP şu özellikleriyle öne çıkar:
- XML tabanlı mesaj zarfı
- Ayrıntılı ve biçimsel servis sözleşmeleri
- Mesaj seviyesinde güvenlik ve kurumsal standartlarla çalışma imkânı
- HTTP dışındaki taşıma protokollerini kullanabilme
- Finans, telekom ve eski kurumsal sistemlerde yaygın kullanım
SOAP mesajları REST/JSON yapılarına göre daha ayrıntılı olabilir. Ancak güçlü sözleşme ve mevcut kurumsal altyapıyla uyumluluk gereken projelerde tercih edilebilir.
GraphQL Nedir?
GraphQL, API’ler için açık kaynaklı bir sorgu dili ve sunucu tarafı çalışma zamanıdır. İstemci, hangi alanlara ihtiyaç duyduğunu sorguda belirtir; sunucu tanımlı şemaya göre yalnızca ilgili veriyi döndürebilir.
GraphQL üç temel işlem türü sunar:
- Query: Veri okumak
- Mutation: Veri değiştirmek
- Subscription: Belirli olaylarda güncelleme almak
GraphQL özellikle birbiriyle ilişkili çok sayıda verinin farklı ekranlarda farklı biçimlerde istendiği uygulamalarda esneklik sağlayabilir. Bununla birlikte sorgu karmaşıklığı, yetkilendirme, önbellek ve kaynak tüketimi dikkatle yönetilmelidir.
REST, SOAP ve GraphQL Karşılaştırması
| Kriter | REST | SOAP | GraphQL |
|---|---|---|---|
| Yapı | Mimari yaklaşım | Mesajlaşma protokolü | Sorgu dili ve çalışma zamanı |
| Yaygın veri formatı | JSON | XML | Genellikle JSON |
| Endpoint yapısı | Kaynak bazlı çoklu endpoint | Servis işlemleri | Çoğunlukla tek GraphQL endpoint’i |
| Veri seçimi | Sunucunun tanımladığı yanıt | Sözleşmede tanımlı mesaj | İstemci ihtiyaç duyduğu alanları seçer |
| Güçlü yönü | Sadelik ve geniş ekosistem | Biçimsel sözleşme ve kurumsal uyum | Esnek veri sorgulama |
| Dikkat edilmesi gereken | Sürüm ve kaynak tasarımı | Mesaj karmaşıklığı | Sorgu maliyeti ve yetkilendirme |
“En iyi API türü” yoktur. Mevcut sistem, ekip deneyimi, istemci sayısı, güvenlik, performans ve veri sorgulama ihtiyacı birlikte değerlendirilmelidir.
Webhook Nedir? API’den Farkı Nedir?
Webhook, bir sistemde belirli olay gerçekleştiğinde başka sistemin belirlediği URL’ye otomatik HTTP isteği gönderilmesidir. GitHub’ın tanımıyla webhook, bir yazılım sistemindeki olaylara abone olmayı ve olay gerçekleştiğinde sunucuya veri teslim edilmesini sağlar.
API’de istemci genellikle “Yeni bir bilgi var mı?” diye istek gönderir. Webhook’ta ise kaynak sistem olay oluşunca karşı tarafa haber verir.
Ödeme örneği:
- E-ticaret yazılımı ödeme API’siyle işlem başlatır.
- Ödeme kuruluşu işlemi tamamlar.
- Sonuç webhook ile e-ticaret sistemne gönderilir.
- Sistem imzayı doğrular ve siparişi günceller.
Webhook entegrasyonunda imza doğrulama, tekrar gönderim, idempotency ve olay sırasının değişebilmesi dikkate alınmalıdır. Endpoint’in 200 yanıtı vermesi tek başına iş kuralının başarıyla tamamlandığı anlamına gelmemelidir; olay güvenilir biçimde kuyruğa alındıktan sonra işlenebilir.
API Kimlik Doğrulama Yöntemleri
API’nin çağrıyı kimin yaptığını ve hangi işlemlere yetkili olduğunu belirlemesi gerekir.
API key
Uygulamaya verilen tanımlayıcı bir anahtardır. Basit servis erişimlerinde kullanılabilir. API key tek başına kullanıcı yetkilendirmesi için her zaman yeterli değildir ve istemci tarafındaki halka açık koda gömülmemelidir.
Token tabanlı doğrulama
Kullanıcı veya uygulama doğrulandıktan sonra belirli süre ve kapsamla erişim token’ı alır. Token her istekte gönderilir. Süre, kapsam, iptal ve güvenli saklama doğru yönetilmelidir.
OAuth 2.0
OAuth, kullanıcının parolasını üçüncü taraf uygulamayla paylaşmadan belirli kaynaklara sınırlı erişim yetkisi vermesini sağlayan yetkilendirme çerçevesidir. “Google hesabıyla bağlan” veya bir uygulamaya takvim erişimi verme gibi senaryolarda kullanılabilir.
OAuth akışı istemci türüne göre doğru seçilmeli ve RFC 9700’deki güncel güvenlik uygulamaları dikkate alınmalıdır. OAuth 2.0 tek başına bir kimlik doğrulama protokolü değildir; kullanıcı kimliği için genellikle OpenID Connect gibi ek katman kullanılır.
mTLS
Karşılıklı TLS’de hem istemci hem sunucu sertifikayla birbirini doğrular. Kurumlar arası ve yüksek güven gerektiren servis iletişimlerinde tercih edilebilir.
Kimlik doğrulama “Kim çağrı yapıyor?” sorusunu; yetkilendirme ise “Bu çağrıyı yapan hangi kaynağa, hangi işlemle erişebilir?” sorusunu cevaplar. API güvenliğinde ikisi ayrı ayrı kontrol edilmelidir.
Rate Limit Nedir?
Rate limit, bir istemcinin belirli süre içinde yapabileceği işlem veya istek sayısını sınırlar. Sistemin aşırı yüklenmesini, kötüye kullanımı ve bazı hizmet engelleme saldırılarını azaltmaya yardımcı olur.
Limit aşıldığında API 429 Too Many Requests yanıtı verebilir. Retry-After header’ı istemcinin tekrar denemeden önce ne kadar beklemesi gerektiğini gösterebilir.
İstemci tarafında:
- Limit bilgileri izlenmeli,
- Geçici hatalarda artan bekleme uygulanmalı
- Aynı istek sonsuz döngüyle tekrar edilmemeli,
- Toplu veri işlemleri için uygun endpoint kullanılmalı,
- Başarısız istekler loglanmalıdır.
Rate limit yalnızca IP adresine göre değil kullanıcı, uygulama, endpoint veya işlem maliyetine göre de uygulanabilir.
API Entegrasyonu Nasıl Yapılır?
API entegrasyonu, iki sistem arasında tek seferlik bağlantı kurmaktan daha fazlasıdır. Veri sahipliği, hata yönetimi ve operasyonel izleme baştan planlanmalıdır.
1. İş akışını tanımlayın
Hangi olayın hangi işlemi başlatacağı belirlenir. Örneğin sipariş oluştuğunda ERP’ye ne zaman aktarılacağı, stok bilgisinin hangi sistemden alınacağı ve iptalde ne yapılacağı netleştirilir.
2. Dokümantasyonu inceleyin
Endpoint’ler, metotlar, veri alanları, kimlik doğrulama, rate limit, hata kodları, test ortamı ve sürüm politikası kontrol edilir.
3. Veri eşleştirmesi yapın
İki sistem aynı kavramı farklı alanlarla ifade edebilir. Ürün kodu, müşteri kimliği, vergi, para birimi, tarih ve durum değerleri eşleştirilir.
4. Güvenlik modelini kurun
Anahtar ve token’lar kod içine yazılmaz; güvenli sır yönetiminde tutulur. Yetkiler mümkün olan en dar kapsamla verilir. HTTPS, IP veya sertifika kısıtları ve anahtar yenileme süreci planlanır.
5. Hata ve tekrar senaryolarını tasarlayın
Karşı servis yanıt vermezse, aynı istek iki kez ulaşırsa veya işlemin yarısı tamamlanırsa ne olacağı belirlenir. Otomatik tekrar, kuyruk, idempotency ve manuel mutabakat mekanizmaları gerekebilir.
6. Test ortamında doğrulayın
Başarılı akışın yanında eksik veri, yetkisiz erişim, zaman aşımı, rate limit, mükerrer kayıt, iptal ve iade senaryoları test edilir.
7. İzleme ve alarm kurun
Entegrasyonun ayakta olması, işlemlerin doğru aktığı anlamına gelmez. Başarı oranı, gecikme, kuyruk uzunluğu, hata türleri ve mutabakat farkları izlenmelidir.
API Entegrasyonu Örnekleri
Ödeme entegrasyonu
Uygulama ödeme oturumu oluşturur, müşteri işlemi tamamlar ve sonuç API veya webhook üzerinden doğrulanır. Tutar, para birimi ve sipariş kimliği sunucu tarafında kontrol edilmelidir.
ERP entegrasyonu
Ürün, stok, fiyat, müşteri, sipariş ve fatura verileri sistemler arasında aktarılabilir. Her veri türü için ana kaynağın hangi sistem olduğu belirlenmelidir.
Kargo entegrasyonu
Gönderi kaydı oluşturma, barkod alma, takip ve teslimat durumları otomatikleştirilebilir. Adres ve paket verisi doğrulanmalı; iptal edilen gönderiler mutabakata alınmalıdır.
CRM entegrasyonu
Form, teklif, satış ve destek verileri CRM’e aktarılabilir. Aynı müşterinin farklı sistemlerde mükerrer oluşmasını önlemek için kimlik eşleştirme kuralı gerekir.
Pazaryeri entegrasyonu
Ürün, fiyat, stok ve sipariş akışları API üzerinden yönetilebilir. Rate limit, farklı kategori yapıları ve kanal bazlı durum kodları dikkate alınmalıdır.
İyi Bir API Nasıl Olmalıdır?
İyi bir API yalnızca çalışan endpoint’lerden oluşmaz. Kullanıcıları ve bakım ekibi için öngörülebilir olmalıdır.
- Tutarlı kaynak ve alan adları kullanır.
- Anlamlı HTTP metotları ve durum kodları döndürür.
- Açık ve güncel dokümantasyona sahiptir
- Örnek istek, yanıt ve hata senaryoları sunar
- Geriye dönük uyumluluk ve sürüm politikasını belirtir
- Kimlik doğrulama ile yetkilendirmeyi doğru uygular.
- Sayfalama, filtreleme ve rate limit davranışını açıklar.
- İsteklerin izlenebilmesi için benzersiz işlem kimliği üretir.
- Hassas veriyi gereğinden fazla döndürmez.
- İzleme ve hata ayıklamayı destekler.
OpenAPI Specification, HTTP API’lerinin yeteneklerini insanlar ve araçların anlayabileceği, programlama dilinden bağımsız biçimde tanımlamak için standart arayüz açıklaması sunar. Bu tür makine tarafından okunabilir sözleşmeler dokümantasyon, test ve istemci üretimini kolaylaştırabilir.
API Versiyonlama Neden Gereklidir?
Bir API kullanıma açıldıktan sonra alan adını değiştirmek veya yanıt yapısını kaldırmak bağlı uygulamaları bozabilir. Bu nedenle geriye dönük uyumsuz değişiklikler kontrollü sürüm politikasıyla yönetilmelidir.
Yaygın yöntemler:
- URL’de sürüm: /v1/orders
- Header veya medya türüyle sürüm
- Geriye uyumlu alan eklemeleri
- Eski sürüm için kullanım sonu ve kapanış tarihi
Yeni sürüm yayınlandığında entegrasyon sahiplerine geçiş süresi, değişiklik listesi ve test ortamı sağlanmalıdır. Eski sürüm sessizce kapatılmamalıdır.
API Güvenliğinde Dikkat Edilmesi Gerekenler
API, uygulamanın verisine ve işlevlerine doğrudan erişim sunduğu için önemli saldırı yüzeyidir. OWASP API Security Top 10; nesne düzeyinde yetki hataları, bozuk kimlik doğrulama, kontrolsüz kaynak tüketimi ve güvenli olmayan üçüncü taraf API kullanımı gibi risklere dikkat çeker.
Temel güvenlik önlemleri şunlardır:
- Bütün bağlantılarda HTTPS kullanmak
- Her endpoint’te kimlik ve yetki kontrolü yapmak
- Kullanıcının yalnızca kendi kayıtlarına erişmesini doğrulamak
- İstek verisini sunucu tarafında kontrol etmek
- Yalnızca gerekli alanları döndürmek
- Token ve API anahtarlarını güvenli saklamak
- Anahtarları yenilemek ve iptal edebilmek
- Rate limit ve kaynak kotası uygulamak
- Hassas veriyi loglara yazmamak
- API envanteri ve sürüm takibi yapmak
- Bağımlılıkları ve API gateway yapılandırmasını güncel tutmak
- Olağan dışı kullanım için alarm üretmek
Örneğin kullanıcı /orders/1250 adresindeki kendi siparişini görebiliyor diye /orders/1251 adresine geçtiğinde başka müşterinin siparişini görememelidir. Yalnızca oturum açılmış olması yeterli değildir; her kayıt erişiminde nesne düzeyinde yetkilendirme yapılmalıdır.
API Entegrasyonunda Yapılan Yaygın Hatalar
- Dokümantasyonu okumadan yalnızca örnek isteği kopyalamak
- Test ve canlı ortam anahtarlarını karıştırmak
- Token ve şifreleri kaynak koda yazmak
- Her hatada aynı isteği sınırsız tekrar etmek
- Mükerrer işlem ihtimalini düşünmemek
- Webhook imzasını doğrulamamak
- Stok veya müşteri verisinin ana kaynağını belirlememek
- Rate limit ve sayfalamayı göz ardı etmek
- API değişikliklerini ve kullanım sonu duyurularını izlememek
- Hata logu ve mutabakat ekranı oluşturmamak
Entegrasyon başarılı yanıt verdiği ilk gün tamamlanmış sayılmaz. Sürekli izleme, bakım ve karşı sistem değişikliklerine uyum gerekir.
EKKASOFT ile Özel API ve Sistem Entegrasyonları
EKKASOFT, işletmeler için özel web, mobil, operasyon ve e-ticaret yazılımları geliştirir. Ödeme ve ERP entegrasyonlarını yalnızca iki sistem arasında veri taşıyan bağlantılar olarak değil, işletmenin gerçek iş akışının parçaları olarak ele alır.
EKKASOFT’un keşif aşamasında mevcut sistemler, kullanıcı rolleri, veri kaynakları ve manuel işlemler incelenebilir. Çözüm tasarımında hangi sistemin ana veri kaynağı olacağı, API akışları, hata senaryoları ve yetkiler planlanır. Geliştirme süreci düzenli demolarla ilerler; test ve canlıya alma sonrasında izleme, bakım ve destek ile entegrasyonun sürdürülebilirliği hedeflenir.
EKKASOFT ile planlanabilecek çalışmalar şunlardır:
- Mevcut sisteme özel REST API geliştirme
- Web ve mobil uygulamalar için ortak backend API’si
- Ödeme ve ERP entegrasyonları
- CRM, kargo, e-fatura veya işletmeye özel servis bağlantıları
- API ile eski sistem arasında ara katman geliştirme
- Webhook ve olay tabanlı iş akışları
- Entegrasyon logları ve mutabakat panelleri
- API güvenliği, yetkilendirme ve rate limit tasarımı
Hazır bağlantıların karşılamadığı iş kurallarına, dağınık sistemler arasında otomatik veri akışına veya iş ortaklarına açılacak güvenli bir API’ye ihtiyaç duyan işletmeler EKKASOFT ile iletişime geçerek entegrasyon kapsamını değerlendirebilir.
Sonuç
API, farklı yazılımların önceden tanımlanmış kurallarla iletişim kurmasını sağlayan uygulama programlama arayüzüdür. İstemci belirli endpoint’e istek gönderir; sunucu kimlik, yetki ve veri kontrollerinden sonra sonucu durum kodu ve veri gövdesiyle döndürür.
REST, SOAP ve GraphQL farklı ihtiyaçlara cevap veren yaklaşımlardır. Webhook ise bir olay oluştuğunda karşı sistemi otomatik haberdar ederek API çağrılarını tamamlar. Doğru seçim mevcut sistemlere, veri yapısına, performansa, güvenliğe ve bakım ihtiyacına göre yapılmalıdır.
Başarılı API entegrasyonunun temelinde yalnızca bağlantı kurmak değil veri sahipliğini belirlemek, mükerrer işlemleri önlemek, hataları izlemek ve sürüm değişikliklerini yönetmek vardır. İyi tasarlanmış API’ler manuel işi azaltır, sistemleri birbirine bağlar ve yeni dijital hizmetlerin daha hızlı geliştirilmesini sağlar.
Web uygulamalarının genel mimarisini incelemek için Web Yazılım Nedir? Modern Web Geliştirme Rehberi, API’lerin çalışacağı altyapı seçenekleri için Bulut Hosting ve VPS Hosting Arasındaki Fark Nedir? yazılarımızı okuyabilirsiniz.
Sıkça Sorulan Sorular
API nedir, basitçe nasıl açıklanır?
API, iki yazılımın hangi işlemleri hangi veri biçimiyle yapabileceğini belirleyen arayüzdür. Bir uygulama API üzerinden başka sistemden veri alabilir veya o sistemde kontrollü işlem başlatabilir.
API ile veri tabanı aynı şey midir?
Hayır. Veri tabanı bilgilerin saklandığı yapıdır. API ise uygulamaların iş kuralları ve yetkiler üzerinden verilere veya işlemlere erişmesini sağlar. Dış uygulamalara doğrudan veri tabanı erişimi vermek yerine API kullanmak genellikle daha kontrollüdür.
REST API nedir?
REST API, kaynakları çoğunlukla URL’lerle temsil eden ve HTTP metotlarını amaçlarına uygun kullanan web API yaklaşımıdır. REST bir protokol değil mimari stildir.
Endpoint nedir?
Endpoint, API’de belirli kaynak veya işleme erişilen adrestir. Örneğin /orders/1250 belirli bir siparişi temsil edebilir.
API key ile token arasındaki fark nedir
API key çoğunlukla çağrıyı yapan uygulamayı tanımlar. Token ise kullanıcı veya uygulamaya belirli süre ve yetki kapsamıyla erişim sağlayabilir. Gerçek davranış kullanılan güvenlik modeline bağlıdır.
API ile webhook arasındaki fark nedir
API’de istemci bilgi almak veya işlem yapmak için istek gönderir. Webhook’ta kaynak sistem, abone olunan olay oluştuğunda karşı tarafın URL’sine otomatik istek gönderir.
API entegrasyonu ne kadar sürer?
Süre; dokümantasyon kalitesi, veri alanları, kimlik doğrulama, iş kuralları, test ortamı ve hata senaryolarına bağlıdır. Basit bağlantı kısa sürebilirken çift yönlü ERP veya ödeme entegrasyonu daha kapsamlı analiz ve test gerektirir.
API kullanmak ücretli midir
Sağlayıcıya göre değişir. Bazı API’ler ücretsiz kota, bazıları çağrı veya işlem başına fiyat, bazıları ise sözleşmeli erişim sunar. Lisansın yanında veri aktarımı ve altyapı maliyeti de değerlendirilmelidir.
EKKASOFT API geliştirme ve entegrasyon hizmeti sunar mı?
EKKASOFT özel web, mobil, operasyon ve e-ticaret yazılımları ile ödeme ve ERP entegrasyonları geliştirir. Diğer API ihtiyaçlarının kapsamı, mevcut sistemler ve iş akışları incelendikten sonra belirlenebilir.