API Nedir? Web ve Mobil Uygulamalarda Nasıl Çalışır?

API Nedir? Uygulamalar ve Web Siteleri Birbirleriyle Nasıl Konuşur?

Telefonundan yemek siparişi verdiğini düşün.

Uygulamayı açıyorsun, restoranları inceliyorsun, beğendiğin yemeği seçiyorsun, adresini giriyorsun ve siparişini tamamlıyorsun.

Birkaç saniye sonra ekranda bir bildirim beliriyor:

“Siparişiniz restorana iletildi.”

Biraz sonra başka bir bildirim geliyor:

“Siparişiniz hazırlanıyor.”

Ardından haritada kuryenin hareket ettiğini görüyorsun.

Şimdi sana bir soru sorayım.

Telefonundaki uygulama, restoranın sipariş sistemine nasıl ulaştı? Ödemenin başarılı olduğunu nereden öğrendi? Kurye hareket ettikçe haritadaki konum nasıl değişti?

Telefonun restoranı aramadı. Kurye sana sürekli mesaj göndermedi. Üstelik bütün bu işlemleri tek bir yazılım da yapmadı.

Arka planda birbirinden farklı sistemler konuştu, bilgi alışverişinde bulundu ve belirli işlemleri gerçekleştirdi.

İşte bu iletişimin merkezinde çoğu zaman API dediğimiz yapı bulunuyor.

Bugün API'nin ne olduğunu sadece tanımını ezberleyerek öğrenmeyeceğiz. Bir uygulamanın içinde neler olup bittiğine bakacağız, küçük bir yazılım geliştireceğiz, kodları inceleyeceğiz ve yazılımların birbirleriyle nasıl anlaştığını birlikte keşfedeceğiz.

Hazırsan uygulamaların görünmeyen tarafına geçelim.

API Nedir? Önce Şu Üç Harfi Tanıyalım

API, İngilizce Application Programming Interface kelimelerinin kısaltmasıdır.

Türkçesi Uygulama Programlama Arayüzü.

İsmi biraz teknik gelebilir. Ama mantığı oldukça anlaşılır.

API, bir yazılımın başka bir yazılımın sunduğu verilere veya işlevlere belirlenmiş kurallar çerçevesinde erişmesini sağlayan arayüzdür.

Bir yazılım diğerine “Bana şu bilgiyi verir misin?” veya “Şu işlemi gerçekleştirir misin?” dediğinde, bu iletişim bir API üzerinden kurulabilir.

Burada önemli bir ayrıntı var: API sadece internet üzerinden çalışan sistemler için kullanılmaz. İşletim sistemlerinin, yazılım kütüphanelerinin ve farklı programlama bileşenlerinin sunduğu arayüzler de API olarak adlandırılır.

Fakat günlük hayatta web ve mobil uygulamalarda en sık karşılaştığımız türlerden biri Web API yapısıdır.

Biz de ağırlıklı olarak bu yapıyı inceleyeceğiz.

API'yi bir restoran üzerinden düşünelim

Bir restorana gittiğini hayal et.

Masaya oturdun, menüden bir pizza seçtin ve garsonu çağırdın.

Garsona şöyle dedin:

“Bir orta boy karışık pizza istiyorum. Mantar olmasın.”

Garson siparişi mutfağa götürdü. Mutfak siparişi değerlendirdi, hazırladı ve garson aracılığıyla sana ulaştırdı.

Bu örnekte:

• Sen: İstekte bulunan kullanıcısın.

• Garson: API'nin iletişimdeki rolüne benziyor.

• Mutfak: İşlemlerin gerçekleştirildiği sunucu ve backend tarafı.

• Sipariş fişi: Gönderilen isteğin taşıdığı bilgiler.

• Hazırlanan pizza: İsteğin sonucunda elde edilen yanıt.

Gördüğün gibi mutfağa girip dolapları karıştırmana gerek yok.

Sen yalnızca ne istediğini belirtiyorsun. Restoranın tanımladığı süreç bu talebi yerine getiriyor.

Bir API de benzer şekilde çalışır.

Fakat önemli bir fark var. Gerçek bir API yalnızca mesaj taşımaz; hangi işlemlerin yapılabileceğini, hangi bilgilerin gönderileceğini ve nasıl yanıt alınacağını da tanımlar.

Yani garson benzetmesi iletişim kısmını anlamak için güzel, ama API aslında bundan biraz daha kapsamlı bir anlaşmadır.

Peki Neden API'ye İhtiyacımız Var?

Diyelim ki bir mobil uygulama geliştirdin.

Uygulamanın içinde kullanıcıların hesap oluşturmasını, giriş yapmasını, fotoğraf yüklemesini ve arkadaşlarına mesaj göndermesini istiyorsun.

İlk bakışta bunlar birkaç ekrandan oluşan basit özellikler gibi görünebilir.

Ama işin arkasında önemli sorular var.

Kullanıcının şifresi nerede kontrol edilecek? Fotoğraflar nerede saklanacak? Mesajlar hangi kullanıcıya ait olacak? Bir kullanıcı başka birinin özel mesajlarını okuyabilecek mi?

Bu işlemleri yalnızca telefonun içinde çözemezsin. Özellikle birden fazla kullanıcının aynı verilerle çalıştığı sistemlerde merkezi bir altyapıya ihtiyaç duyarsın.

İşte burada uygulamanın görünen yüzü ile arka plandaki sistem arasında bir iletişim kurulması gerekir.

Bir tarafta kullanıcıya gösterdiğimiz ekranlar bulunur. Buna frontend diyoruz.

Diğer tarafta verileri işleyen, kuralları uygulayan ve sunucu tarafındaki işlemleri gerçekleştiren yapı vardır. Buna da backend diyoruz.

API, bu iki tarafın haberleşmesini sağlayan temel yöntemlerden biridir.

Şöyle düşün:

Bir okul yönetim sistemi geliştirdiğini varsayalım.

Öğrenci sisteme giriş yaptı ve “Notlarım” sayfasını açtı.

Ekranda henüz hiçbir bilgi yok.

Çünkü uygulamanın önce öğrencinin notlarını ilgili sistemden istemesi gerekiyor.

Bu durumda örnek bir API isteği şöyle olabilir:

GET /api/notlarim HTTP/1.1
Host: ornek.com

Sunucu bu isteği alır, kullanıcının kimliğini doğrular, hangi notları görmeye yetkili olduğunu kontrol eder, veritabanından ilgili bilgileri getirir ve uygulamaya gönderir.

Uygulama da gelen bilgileri güzel bir tasarımla ekrana yerleştirir.

Sonuçta öğrenci yalnızca derslerini ve notlarını görür.

Ama arka planda küçük bir iletişim gerçekleşmiştir.

Ve bu işlem her sayfa açılışında, her veri yenilemesinde veya ilgili değişikliklerde tekrar gerçekleşebilir.

Bir Butona Bastığında Arka Planda Gerçekte Ne Oluyor?

Şimdi biraz daha derine inelim.

Bir uygulamaya girdin. Kullanıcı adını ve şifreni yazdın. Sonra “Giriş Yap” butonuna bastın.

Senin gördüğün şey çok basit: Birkaç saniye yükleme animasyonu ve ardından ana sayfa.

Ama arka planda neler oluyor?

1. Uygulama bilgileri hazırlar

Öncelikle giriş formundaki bilgiler alınır.

Örneğin:

{
  "email": "ornek@eposta.com",
  "password": "ornek-sifre"
}

Bu bilgiler bir isteğin gövdesine yerleştirilebilir.

Burada JSON adı verilen veri biçimini kullanıyoruz. Birazdan onu da açıklayacağım.

2. API isteği gönderilir

Uygulama, sunucudaki giriş işlemini yöneten adrese bir istek gönderir.

Örneğin:

POST /api/auth/login HTTP/1.1
Host: ornek.com
Content-Type: application/json

{
  "email": "ornek@eposta.com",
  "password": "ornek-sifre"
}

İsteğin gövdesinde e-posta ve şifre bilgileri bulunur.

Bu örnekte POST, sunucuya işlenmesi gereken veriler gönderdiğimizi ifade eder.

3. Sunucu isteği karşılar

Sunucu, isteğin hangi işlem için gönderildiğine bakar.

Eğer istek giriş işlemiyle ilgiliyse ilgili backend kodu çalışır.

Backend, uygulamanın arka plandaki iş mantığını yöneten bölümdür.

4. Kimlik bilgileri kontrol edilir

Sunucu, kullanıcıyı kayıtlı bilgiler üzerinden doğrular.

Güvenli bir sistemde şifreler veritabanında düz metin olarak tutulmaz. Uygun parola özetleme yöntemleri kullanılır ve giriş sırasında doğrulama yapılır.

Şifre yanlışsa sistem girişe izin vermez.

Doğruysa oturum oluşturma süreci devam eder.

5. Sunucu cevap gönderir

Başarılı bir girişte API örneğin şöyle bir yanıt verebilir:

{
  "success": true,
  "user": {
    "id": 42,
    "name": "Mehmet",
    "role": "student"
  }
}

Bu basitleştirilmiş bir örnek. Gerçek bir sistemde oturumun güvenli biçimde sürdürülmesi için ayrıca uygun oturum mekanizmaları kullanılır.

6. Uygulama ekrana yansıtır

Frontend gelen yanıtı değerlendirir.

Giriş başarılıysa kullanıcı ilgili sayfaya yönlendirilir.

Başarısızsa hata mesajı gösterilir.

Mesela:

“E-posta adresiniz veya şifreniz hatalı.”

İşte senin gördüğün birkaç saniyelik giriş işleminin arkasında bunlar gerçekleşir.

Kullanıcı girişinde istek–yanıt akışı

API İsteğinin Yapısı: URL, Method, Header ve Body

Biraz önce API'ye istek gönderdik. Fakat bu isteğin içinde tam olarak hangi bilgiler var?

Web API'lerinde HTTP adı verilen iletişim protokolü yaygın olarak kullanılır.

HTTP, istemci ile sunucunun hangi kurallara göre istek ve yanıt alışverişi yapacağını tanımlar.

Bir HTTP isteğinde özellikle dört kavramla sık karşılaşırsın.

1. URL: Nereye gidiyoruz?

Örneğin:

https://ornek.com/api/ogrenciler/42

Bu adresi parçalara ayıralım.

• https:// güvenli HTTP bağlantısını belirtir.

• ornek.com sunucunun alan adıdır.

• /api/ogrenciler/42 istenen kaynağın adresidir.

Buradaki 42, belirli bir öğrencinin kimliğini temsil ediyor olabilir.

API'deki bu tür işlem adreslerine genellikle endpoint denir.

2. Method: Ne yapmak istiyoruz?

Bir veriyi mi okuyacağız? Yeni kayıt mı oluşturacağız? Mevcut bilgiyi mi güncelleyeceğiz?

Bunu HTTP yöntemi belirtir.

Örneğin:

GET /api/ogrenciler/42 HTTP/1.1
Host: ornek.com

Bu istek, 42 numaralı öğrencinin bilgilerini getirmek için kullanılabilir.

3. Header: İsteğin ek bilgileri

Header, isteğin nasıl yorumlanacağı veya hangi bağlamda gönderildiği hakkında bilgi taşır.

Örneğin:

Content-Type: application/json
Authorization: Bearer <erisim-tokeni>

İlk satır, gönderilen içeriğin JSON formatında olduğunu belirtir.

İkinci satır ise kimlik doğrulama amacıyla kullanılan bir erişim belirtecinin gönderilebileceğini gösterir.

Buradaki token örnek amaçlıdır. Gerçek bir erişim belirtecini herkese açık şekilde paylaşmamak gerekir.

4. Body: Ne gönderiyoruz?

Bazı isteklerde sunucuya veri göndermemiz gerekir.

Örneğin yeni öğrenci oluştururken:

{
  "ad": "Ayşe",
  "sinif": 8,
  "sinavGrubu": "LGS"
}

Bu veri isteğin gövdesinde bulunabilir.

Kısacası URL nereye gittiğimizi, method ne yapmak istediğimizi, header gerekli ek bilgileri, body ise gönderdiğimiz içeriği anlatır.

GET, POST, PUT, PATCH ve DELETE Nedir?

Bu kelimeleri ilk defa gören biri şöyle düşünebilir:

“Alt tarafı veri getireceğiz. Neden bu kadar farklı komut var?”

Aslında her birinin ayrı bir görevi var.

Bir öğrenci takip uygulaması geliştirdiğimizi düşünelim.

Buradaki önemli farklardan biri PUT ve PATCH arasındadır.

Örneğin öğrencinin kaydında ad, soyad, telefon ve sınıf bilgileri olsun.

Sadece telefon numarasını değiştirmek istiyorsan PATCH uygun bir seçenek olabilir.

Bütün kaydın yeni temsilini gönderip değiştirmek istiyorsan PUT kullanılabilir.

Bunlar HTTP standartlarının tanımladığı anlamlardır. Bir API tasarlanırken geliştiricinin bu kurallara uygun davranması beklenir.

Birkaç gerçek istek görelim

Öğrencileri listelemek:

GET /api/ogrenciler HTTP/1.1
Host: ornek.com

Yeni öğrenci eklemek:

POST /api/ogrenciler HTTP/1.1
Host: ornek.com
Content-Type: application/json

{
  "ad": "Zeynep",
  "sinif": 10
}

Öğrencinin sınıfını güncellemek:

PATCH /api/ogrenciler/42 HTTP/1.1
Host: ornek.com
Content-Type: application/json

{
  "sinif": 11
}

Öğrenciyi silmek:

DELETE /api/ogrenciler/42 HTTP/1.1
Host: ornek.com

Gördüğün gibi işlemleri birbirinden ayırmak kolaylaşıyor.

JSON Nedir? API'ler Neden Bu Formatı Kullanıyor?

Diyelim ki iki yazılım birbiriyle konuşacak.

Birisi JavaScript ile geliştirilmiş, diğeri Python kullanıyor.

Birbirlerinin değişkenlerini ve veri yapılarını doğrudan anlayamayabilirler.

İşte bu yüzden veriyi ortak bir biçimde ifade etmek işe yarar.

JSON (JavaScript Object Notation), verileri metin biçiminde yapılandırmak için kullanılan yaygın bir formattır.

Örneğin:

{
  "ogrenci": {
    "id": 42,
    "ad": "Zeynep",
    "sinif": 11,
    "aktif": true,
    "dersler": [
      "Matematik",
      "Fizik",
      "Kimya"
    ]
  }
}

Burada:

• id sayısal bir değer.

• ad metin.

• aktif doğru/yanlış bilgisi.

• dersler bir liste.

• ogrenci ise başka bilgileri içinde barındıran nesne.

Bu veriyi JavaScript de Python da diğer pek çok dil de ayrıştırabilir.

JSON'un avantajı sadece okunaklı olması değil, farklı platformlar arasında veri taşımayı kolaylaştırmasıdır.

Ancak bütün API'ler JSON kullanmak zorunda değil. XML, düz metin, ikili veri ve başka formatlar da kullanılabilir.

Şimdi Gerçekten Bir API Yazalım

Buraya kadar kavramlardan bahsettik.

Şimdi küçük bir yazılım geliştirelim. Çünkü bazı şeyleri kod üzerinde görmek çok daha öğretici.

Kendimize basit bir görev takip sistemi oluşturalım.

Sistemimiz üç temel işlem gerçekleştirsin:

1. Var olan görevleri listeleme.

2. Yeni görev ekleme.

3. Görevi tamamlandı olarak işaretleme.

Bunun için JavaScript ve Node.js üzerinde çalışan Express kütüphanesini kullanacağız.

Node.js, JavaScript kodlarını tarayıcı dışında da çalıştırmamızı sağlayan bir çalışma ortamıdır.

Express ise Node.js ile sunucu ve web API geliştirmeyi kolaylaştıran bir kütüphanedir.

Adım 1: Projeyi hazırlayalım

Bilgisayarında Node.js kurulu olduğunu varsayıyoruz.

Terminali aç ve aşağıdaki komutları çalıştır:

mkdir benim-ilk-api
cd benim-ilk-api
npm init -y
npm install express

Bu komutlarla yeni bir proje klasörü oluşturduk ve Express paketini yükledik.

Şimdi proje klasörünün içine server.mjs isimli bir dosya oluşturalım.

Adım 2: İlk API kodumuzu yazalım

import express from "express";

const app = express();
const PORT = 3000;

app.use(express.json());

// Örnek görevlerimiz
let gorevler = [
  {
    id: 1,
    baslik: "JavaScript öğren",
    tamamlandi: true
  },
  {
    id: 2,
    baslik: "API geliştir",
    tamamlandi: false
  }
];

// Sonraki görev numarası
let sonrakiId = 3;

// ------------------------------------
// GET - Görevleri listele
// ------------------------------------

app.get("/api/gorevler", (req, res) => {
  res.json(gorevler);
});

// ------------------------------------
// POST - Yeni görev oluştur
// ------------------------------------

app.post("/api/gorevler", (req, res) => {
  const baslik = req.body?.baslik;

  if (typeof baslik !== "string" || !baslik.trim()) {
    return res.status(400).json({
      hata: "Geçerli bir görev başlığı girin."
    });
  }

  const yeniGorev = {
    id: sonrakiId++,
    baslik: baslik.trim(),
    tamamlandi: false
  };

  gorevler.push(yeniGorev);

  return res.status(201).json(yeniGorev);
});

// ------------------------------------
// PATCH - Görev durumunu güncelle
// ------------------------------------

app.patch("/api/gorevler/:id", (req, res) => {
  const id = Number(req.params.id);

  const gorev = gorevler.find(
    (g) => g.id === id
  );

  if (!gorev) {
    return res.status(404).json({
      hata: "Görev bulunamadı."
    });
  }

  if (typeof req.body?.tamamlandi !== "boolean") {
    return res.status(400).json({
      hata: "tamamlandi alanı true veya false olmalı."
    });
  }

  gorev.tamamlandi = req.body.tamamlandi;

  return res.json(gorev);
});

// ------------------------------------
// Sunucuyu başlat
// ------------------------------------

app.listen(PORT, () => {
  console.log(
    `API çalışıyor: http://localhost:${PORT}`
  );
});

Biraz uzun göründüğünün farkındayım. Ama aslında burada yaptığımız şey oldukça basit.

Kodun ilk kısmında Express'i projeye dahil ediyoruz.

import express from "express";

const app = express();

Bu satırlarla sunucu uygulamamızı oluşturuyoruz.

Ardından görevlerimizi bir dizi içinde tutuyoruz.

let gorevler = [
  {
    id: 1,
    baslik: "JavaScript öğren",
    tamamlandi: true
  },
  {
    id: 2,
    baslik: "API geliştir",
    tamamlandi: false
  }
];

Şimdilik gerçek bir veritabanı kullanmıyoruz.

Verileri doğrudan sunucu belleğinde tutuyoruz. Bu yüzden sunucu yeniden başlatıldığında yeni eklediğimiz görevler kaybolur.

Gerçek bir projede PostgreSQL, MySQL veya başka bir kalıcı veri saklama çözümü kullanabiliriz.

Adım 3: API'yi başlatalım

Terminalde şu komutu çalıştır:

node server.mjs

Sunucumuz çalışmaya başlayacak.

Şimdi tarayıcıdan şu adresi açalım:

http://localhost:3000/api/gorevler

Karşımıza aşağıdakine benzer bir yanıt çıkacak:

[
  {
    "id": 1,
    "baslik": "JavaScript öğren",
    "tamamlandi": true
  },
  {
    "id": 2,
    "baslik": "API geliştir",
    "tamamlandi": false
  }
]

İşte ilk API'miz çalışıyor!

Dikkat edersen ortada henüz güzel bir kullanıcı arayüzü yok.

Ne kart var ne buton ne de tasarım.

Sadece veri var.

Çünkü API'nin görevi çoğu zaman ekranda güzel görünmek değil, ihtiyaç duyulan veri ve işlemleri tanımlı biçimde sunmaktır.

Adım 4: Yeni görev gönderelim

Şimdi ikinci API adresimizi test edelim.

Terminalde başka bir pencere açıp şu komutu çalıştırabilirsin:

curl -X POST http://localhost:3000/api/gorevler \
  -H "Content-Type: application/json" \
  -d '{"baslik":"İlk API projemi tamamla"}'

Bu komut macOS ve Linux terminalinde kullanılabilir. Windows PowerShell ortamında da curl.exe ile uygun sözdizimi kullanılabilir.

Sunucu, gönderdiğimiz başlığı alacak, yeni bir görev oluşturacak ve şu cevaba benzer bir yanıt döndürecek:

{
  "id": 3,
  "baslik": "İlk API projemi tamamla",
  "tamamlandi": false
}

Az önce iki farklı işlem gerçekleştirdik.

İlkinde sunucudan bilgi istedik.

İkincisinde sunucuya yeni bilgi gönderdik.

Bütün bunları kullanıcı arayüzü oluşturmadan yaptık.

API'nin güzel taraflarından biri de bu: Aynı backend altyapısını farklı istemciler kullanabilir.

Adım 5: Görevi tamamlandı olarak işaretleyelim

Şimdi daha önce oluşturduğumuz görevin durumunu değiştirelim.

curl -X PATCH http://localhost:3000/api/gorevler/3 \
  -H "Content-Type: application/json" \
  -d '{"tamamlandi":true}'

Sunucu şu şekilde cevap verebilir:

{
  "id": 3,
  "baslik": "İlk API projemi tamamla",
  "tamamlandi": true
}

Burada yalnızca görevin tamamlanma durumunu değiştirdik.

Görevin başlığı aynı kaldı.

İşte PATCH yönteminin mantığını küçük bir örnek üzerinden görmüş olduk.

Peki Bu API'yi Bir Web Sitesine Nasıl Bağlayacağız?

Şimdi en eğlenceli kısma geldik.

Az önce geliştirdiğimiz API, verileri JSON olarak gönderiyor.

Fakat kullanıcılarımız JSON dosyalarına bakarak görevlerini yönetmek istemeyecek.

Onlar güzel bir ekranda görevlerini görmek ve yeni görev eklemek isteyecekler.

İşte burada frontend devreye giriyor.

JavaScript'in fetch() fonksiyonuyla API'ye istek gönderebiliriz.

Örneğin:

async function gorevleriGetir() {
  try {
    // API'ye GET isteği gönder
    const response = await fetch("/api/gorevler");

    // HTTP yanıtını kontrol et
    if (!response.ok) {
      throw new Error(
        `HTTP hatası: ${response.status}`
      );
    }

    // JSON yanıtını JavaScript verisine dönüştür
    const gorevler = await response.json();

    console.log("Görevlerimiz:", gorevler);

  } catch (error) {
    console.error(
      "Görevler alınamadı:",
      error
    );
  }
}

Buradaki fetch() fonksiyonu, belirtilen adrese HTTP isteği göndermemizi sağlar.

await ise asenkron işlemin sonucunu beklemek için kullanılır.

Sunucunun cevabı geldiğinde response.json() ile veriyi JavaScript tarafında kullanabileceğimiz yapıya dönüştürürüz.

Peki yeni görev eklemek istersek?

async function gorevEkle(baslik) {
  const response = await fetch("/api/gorevler", {
    method: "POST",

    headers: {
      "Content-Type": "application/json"
    },

    body: JSON.stringify({
      baslik: baslik
    })
  });

  if (!response.ok) {
    throw new Error("Görev eklenemedi.");
  }

  const yeniGorev = await response.json();

  return yeniGorev;
}

Bu fonksiyonu bir butona bağlayabiliriz.

Kullanıcı görev başlığını yazdığında frontend bu bilgiyi API'ye gönderir. Sunucu da yeni kaydı oluşturur.

Peki bir görev başarıyla eklendiğinde ekranda ne olacak?

Frontend, yeni görevi görev listesine dahil edebilir veya API'den listeyi tekrar alabilir.

Böylece kullanıcı yeni görevi anında görür.

Küçük bir teknik not: Yukarıdaki fetch() örneklerinde aynı alan adı üzerinden erişim varsayıyoruz. Frontend başka bir portta veya alan adında çalışıyorsa tam API adresini kullanmak ve uygun CORS yapılandırmasını yapmak gerekebilir.

Artık zincirin tamamını görmüş olduk:

Kullanıcı butona basıyor, frontend API'ye istek gönderiyor, backend işlemi yapıyor, sonuç tekrar frontend'e ulaşıyor ve ekran güncelleniyor.

Gerçek uygulamaların oldukça büyük bir bölümü bu temel mantığın üzerine kuruluyor.

API ile Veritabanı Aynı Şey mi?

Hayır. Üstelik bu iki kavram çok sık karıştırılıyor.

Bir öğrenci takip sistemi geliştirdiğini düşün.

Sistemde öğrencilerin adları, sınıfları, sınav sonuçları, çalışma programları ve öğretmen notları bulunuyor.

Bunların kalıcı olarak saklanması gerekiyor.

İşte bu noktada veritabanı devreye giriyor.

Veritabanı, bilgilerin belirli bir düzen içinde saklanmasını ve yönetilmesini sağlayan sistemdir.

API ise uygun durumlarda bu verilere erişmek veya onlar üzerinde işlem yapmak için kullanılan arayüzdür.

Şöyle düşün:

Veritabanı bir kütüphane arşivi olsun.

API ise arşivden hangi kitabın hangi kurallarla alınabileceğini tanımlayan hizmet noktası gibi düşünülebilir.

Kütüphanenin bütün raflarını herkesin kullanımına açmak istemezsin.

Birisinin kütüphaneye girip bütün kitapları değiştirebilmesi de doğru olmaz.

Bu nedenle yazılımda kimlik doğrulama, yetkilendirme ve veri erişim kuralları önemli hale gelir.

Gerçek bir sistemin yapısı nasıl olur?

Basitleştirilmiş bir mimariyi düşünelim:

KULLANICI
    |
    v
MOBİL UYGULAMA / WEB SİTESİ
    |
    | HTTP isteği
    v
API
    |
    v
BACKEND
    |
    | İş kuralları
    | Yetki kontrolü
    v
VERİTABANI
    |
    | İstenen kayıtlar
    v
BACKEND
    |
    | HTTP yanıtı
    v
MOBİL UYGULAMA / WEB SİTESİ

Bu yalnızca sık kullanılan mimarilerden biri. Bazı sistemlerde API ile veritabanı arasında ayrıca servisler bulunabilir. Bazılarında ise yönetilen backend servisleri kullanılır.

Temel mantık ise aynı kalır: Veri erişimi ve kullanıcıya sunulan deneyim belirli kurallar çerçevesinde birlikte çalışır.

Her İşlem İçin Mutlaka API Çağrısı Yapmak Gerekir mi?

Hayır.

Örneğin bir hesap makinesi uygulaması geliştirdin.

Kullanıcı iki sayı giriyor ve uygulama bu sayıları topluyor.

Bunun için mutlaka internet üzerinden bir sunucuya istek göndermeye ihtiyacın yok.

Hesaplama doğrudan kullanıcının cihazında yapılabilir.

Küçük bir JavaScript örneğine bakalım:

function topla(sayi1, sayi2) {
  return sayi1 + sayi2;
}

const sonuc = topla(15, 25);

console.log(sonuc); // 40

Gördüğün gibi burada bir API isteğine ihtiyaç duymadık.

Ama işlem sunucudaki kayıtlara, başka kullanıcıların bilgilerine veya harici bir hizmete ihtiyaç duyuyorsa API kullanımı anlamlı hale gelebilir.

Buradaki asıl soru şu:

Bu işlem nerede gerçekleştirilmeli ve hangi verilere erişmesi gerekiyor?

İyi bir yazılım mimarisi oluştururken her işlemi gereksiz yere sunucuya göndermek de, bütün iş mantığını kullanıcı cihazına taşımak da doğru yaklaşım değildir.

REST API Nedir? Neden Bu Kadar Sık Duyuyoruz?

API konusunu araştırırken mutlaka REST kelimesiyle karşılaşacaksın.

REST, Representational State Transfer ifadesinin kısaltmasıdır.

Basitçe anlatırsak REST, web üzerinde kaynaklarla çalışırken belirli mimari ilkeler izlemeyi öneren bir yaklaşımdır.

REST tarzında tasarlanmış API'lere genellikle REST API denir.

Örneğin bir kitap uygulamasında şöyle adresler bulunabilir:

GET    /api/kitaplar
GET    /api/kitaplar/12
POST   /api/kitaplar
PUT    /api/kitaplar/12
PATCH  /api/kitaplar/12
DELETE /api/kitaplar/12

Gördüğün gibi işlem yapısı oldukça anlaşılır.

İlk adres kitapları listeler.

İkincisi belirli bir kitabı getirir.

Üçüncüsü yeni kitap oluşturmak için kullanılır.

Dördüncüsü kaynağı bütünüyle değiştirmek için kullanılabilir.

Beşincisi kitabın belirli bilgilerini değiştirir.

Altıncısı da ilgili kitabı siler.

REST'in avantajlarından biri, kaynaklar ve HTTP yöntemleri üzerinden tutarlı API tasarımları oluşturmayı kolaylaştırmasıdır.

Ancak yalnızca HTTP üzerinden JSON göndermek, bir API'nin bütün REST ilkelerini karşıladığı anlamına gelmez.

REST dışında API türleri de var mı?

Elbette.

GraphQL: İstemcinin ihtiyaç duyduğu veri alanlarını sorgu içinde belirtmesine olanak sağlayan bir API sorgulama yaklaşımıdır. Özellikle karmaşık ve ilişkili verilerin bulunduğu uygulamalarda yararlı olabilir.

SOAP: Mesaj yapıları ve iletişim kuralları tanımlanmış, XML tabanlı bir protokoldür. Bazı kurumsal sistemlerde kullanılır.

WebSocket: İstemci ile sunucu arasında uzun süreli, çift yönlü iletişim kurulmasını sağlar. Canlı sohbet ve gerçek zamanlı güncellemelerde tercih edilebilir. Teknik olarak WebSocket, REST'e alternatif bir API tasarım standardından ziyade farklı bir iletişim protokolüdür.

Şunu unutma: Bunların hiçbiri her proje için tek başına en iyi seçenek değildir.

Kullanıcı sayısı, veri yapısı, gerçek zamanlı ihtiyaçlar, güvenlik ve geliştirme maliyeti gibi faktörlere göre uygun teknoloji belirlenir.

API Hataları Nedir? 200, 404 ve 500 Sayıları Ne Anlama Geliyor?

Bir web sitesinde mutlaka “404 Not Found” hatasını görmüşsündür.

Peki bu sayı ne anlatıyor?

HTTP iletişiminde sunucu, isteğin sonucunu bir durum koduyla bildirir.

Bu kodlar, isteğin başarılı olup olmadığını veya neden başarısız olduğunu anlamamıza yardımcı olur.

Örneğin bir öğrencinin bilgilerini görüntülemek istedin.

Ama sistemde o öğrenci bulunmuyor.

API şu yanıtı verebilir:

{
  "success": false,
  "message": "Öğrenci bulunamadı."
}

Bununla birlikte HTTP durum kodu 404 olur.

Frontend de buna göre kullanıcıya anlaşılır bir uyarı gösterebilir.

Önemli bir nokta daha var: Bir API'nin her koşulda 200 döndürmesi doğru değildir.

İşlem başarısız olduğu halde başarılıymış gibi yanıt vermek, hataların yönetilmesini zorlaştırır.

Ayrıca JavaScript'te fetch() kullanıyorsan HTTP 404 veya 500 yanıtlarının otomatik olarak catch bölümüne düşmediğini bilmelisin. Bu yüzden response.ok kontrolü yapmak önemlidir.

API Güvenliği: Herkes Her Veriye Ulaşabilir mi?

Şimdi biraz ciddi bir konuya gelelim.

Diyelim ki bir eğitim platformu geliştirdin.

Platformda 500 öğrenci bulunuyor.

Her öğrenci kendi notlarını, sınav sonuçlarını ve çalışma programlarını görüntüleyebiliyor.

Öğrenci A, aşağıdaki adrese istek gönderdi:

GET /api/ogrenciler/15/notlar HTTP/1.1
Host: ornek.com

Sistem de öğrencinin notlarını getirdi.

Buraya kadar her şey normal.

Peki aynı öğrenci adresin sonundaki 15 değerini değiştirip 16 yaparsa ne olacak?

GET /api/ogrenciler/16/notlar HTTP/1.1
Host: ornek.com

Eğer sistem yalnızca öğrencinin giriş yapmış olup olmadığını kontrol ediyorsa ciddi bir güvenlik sorunu ortaya çıkabilir.

Çünkü kullanıcı giriş yapmış olsa bile başka bir öğrencinin özel verilerini görmeye yetkili değildir.

İşte burada iki kavramı ayırmamız gerekiyor.

Authentication: Sen kimsin?

Kimlik doğrulama işlemidir.

Sistem, isteği gönderen kişinin kim olduğunu belirlemeye çalışır.

Authorization: Neye erişebilirsin?

Yetkilendirme işlemidir.

Sistem, doğrulanmış kullanıcının ilgili işlemi yapmaya veya kaynağı görmeye izni olup olmadığını kontrol eder.

Bu ikisi aynı şey değildir.

Bir öğretmenin sisteme giriş yapması, bütün kurumların öğrenci bilgilerini görüntüleyebileceği anlamına gelmez.

API güvenliğinde özellikle şu önlemler önemlidir:

• Kullanıcı kimliğini ve oturumunu güvenli doğrulamak.

• Her kritik işlemde yetki kontrolü yapmak.

• HTTPS üzerinden iletişim kurmak.

• Gelen verileri doğrulamak.

• Gereksiz kişisel bilgileri API yanıtlarına eklememek.

• İstek sınırları uygulamak.

• Hata kayıtlarını ve şüpheli işlemleri izlemek.

• Gizli API anahtarlarını istemci kodunda açığa çıkarmamak.

Özellikle kullanıcı kimliğine göre veri erişimi konusu önemlidir. OWASP'ın API güvenliği çalışmalarında da kaynak düzeyinde yetkilendirme hataları önemli risklerden biri olarak ele alınır.

API anahtarı nedir?

Bazı servisler, hizmetlerine erişim sağlamak için geliştiricilere API anahtarı verir.

Bu anahtar, uygulamanın veya geliştiricinin bir hizmete erişimini tanımlamak için kullanılabilir.

Örneğin bir yapay zekâ servisinden API anahtarı aldığını düşün.

Yanlış yaklaşım, gizli anahtarı mobil uygulamanın içine gömüp herkese dağıtmaktır.

Çünkü mobil uygulamanın kodu ve gönderdiği istekler incelenebilir.

Genellikle daha güvenli yaklaşım, gizli anahtarı backend tarafında veya uygun sunucu ortamında tutmak ve yetkili işlemleri oradan gerçekleştirmektir.

Burada ayrıca kullanıcı başına kota, istek doğrulama ve maliyet kontrolü yapılabilir.

Her API anahtarı aynı güvenlik modeline sahip değildir; bazı servisler istemci kullanımı için kısıtlanabilir, herkese açık anahtarlar da sunar. Bu yüzden servis sağlayıcısının güvenlik modeline göre hareket edilmelidir.

CORS Nedir? API Çalışıyor Ama Tarayıcı Neden Hata Veriyor?

Yazılıma yeni başlayanların sık karşılaştığı sorunlardan biri de budur.

Backend çalışıyor.

API'yi doğrudan açınca veriler geliyor.

Fakat frontend üzerinden istek gönderdiğinde tarayıcı hata gösteriyor.

Örneğin:

Access to fetch has been blocked by CORS policy

Bunu gördüğünde hemen API'nin bozuk olduğunu düşünme.

CORS (Cross-Origin Resource Sharing), tarayıcıların farklı kaynaklar arasında yapılan belirli isteklere ait yanıtların JavaScript tarafından okunup okunamayacağını kontrol etmek için kullandığı mekanizmadır.

Örneğin frontend şu adreste çalışsın:

https://uygulamam.com

Backend ise şu adreste olsun:

https://api.uygulamam.com

Bu iki adres farklı origin olarak değerlendirilir.

Tarayıcı, ilgili CORS kuralları gereği sunucunun bu erişime izin verip vermediğini kontrol edebilir.

İzin uygun şekilde tanımlanmamışsa frontend yanıtı okuyamaz.

Burada çözüm, rastgele bütün güvenlik ayarlarını kapatmak değildir.

Sunucuda güvenilen kaynaklara uygun CORS izinlerini tanımlamak gerekir.

Örneğin Express tarafında cors paketinden yararlanılabilir.

npm install cors

Ardından:

import express from "express";
import cors from "cors";

const app = express();

app.use(cors({
  origin: "https://uygulamam.com",
  methods: ["GET", "POST", "PATCH", "DELETE"],
  allowedHeaders: ["Content-Type", "Authorization"]
}));

app.use(express.json());

Bu örnekte yalnızca belirlediğimiz kaynağa izin veriyoruz.

Elbette gerçek projede CORS ayarları kullanılan kimlik doğrulama ve oturum mekanizmasına göre değerlendirilmelidir.

Önemli bir ayrıntı: CORS, tek başına kimlik doğrulama veya veri yetkilendirme sistemi değildir. Sunucunun erişim kurallarının yerine geçmez.

API'ler Sadece Veri Getirmek İçin mi Kullanılır?

Kesinlikle hayır.

Şimdi biraz günlük hayata dönelim.

API'leri düşündüğünden çok daha fazla yerde kullanıyorsun.

1. Harita ve konum hizmetleri

Bir uygulama içinde adres seçiyorsun.

Harita açılıyor, bulunduğun konum gösteriliyor, bir yere yol tarifi oluşturuluyor.

Bunun için Google Maps gibi servislerin sunduğu API'lerden yararlanılabilir.

2. Ödeme sistemleri

Bir e-ticaret uygulamasında ödeme gerçekleştirdiğini düşün.

Uygulama, ödeme hizmetiyle güvenli biçimde iletişim kurmak zorunda.

Ödeme isteğinin oluşturulması, işlemin sonucunun alınması ve siparişin durumunun güncellenmesi gibi süreçlerde API'ler görev alır.

Ödeme bilgilerinin güvenli işlenmesi ayrıca özel standartlar ve servis sağlayıcısının sunduğu entegrasyon yöntemleri gerektirir.

3. Yapay zekâ sistemleri

Bir uygulamaya yapay zekâ destekli soru çözme özelliği eklemek istediğini düşün.

Kullanıcı bir soru yazıyor veya görsel yüklüyor.

Uygulamanın backend tarafı, uygun bir yapay zekâ API'sine istek gönderiyor.

Model bu isteği işleyip cevap oluşturuyor.

Sonuç tekrar uygulamaya iletiliyor.

Kullanıcı yalnızca soruyu ve cevabı görüyor.

Ama arka planda iki farklı sistem birbiriyle iletişim kuruyor.

4. Kargo ve sipariş takibi

Bir alışveriş sitesinden ürün aldın.

Sipariş sayfasında:

“Kargoya verildi.”

“Dağıtıma çıktı.”

“Teslim edildi.”

gibi bilgiler bulunuyor.

E-ticaret sistemi, kargo firmasının sunduğu entegrasyonlar üzerinden güncel gönderi durumlarını öğrenebilir.

Böylece farklı iki şirketin yazılımı birbiriyle haberleşebilir.

5. Hava durumu uygulamaları

Telefonunda hava durumuna baktığında sıcaklık, rüzgâr, yağış ihtimali ve tahmin bilgilerini görürsün.

Uygulamanın bütün meteoroloji ölçümlerini kendisinin yapması gerekmiyor.

İlgili verileri sağlayan servislerden API aracılığıyla alabilir.

Yani API sayesinde her yazılımın her özelliği sıfırdan geliştirmesine gerek kalmaz.

Webhook Nedir? API'den Ne Farkı Var?

Şimdi küçük ama önemli bir ayrıntıdan bahsedelim.

Bir ödeme sistemi düşün.

Kullanıcı ödeme işlemini başlattı. Fakat ödemenin tamamlanması birkaç saniye sürebilir.

Senin uygulaman her saniye ödeme sağlayıcısına şu soruyu sorabilir:

“Ödeme tamamlandı mı?”

“Şimdi tamamlandı mı?”

“Peki şimdi?”

Teknik olarak bazı sistemlerde durum sorgulama yapılabilir, ama sürekli sorgulama her zaman verimli bir yöntem değildir.

İşte burada webhook devreye girebilir.

Webhook, belirli bir olay gerçekleştiğinde bir sistemin başka bir sisteme otomatik olarak HTTP bildirimi göndermesi için kullanılan mekanizmadır.

Örneğin ödeme başarılı olduğunda ödeme sağlayıcısı senin sunucuna bir bildirim gönderebilir.

Senin backend'in de bu bildirimi doğruladıktan sonra siparişin durumunu güncelleyebilir.

Örnek bir webhook verisi şöyle olabilir:

{
  "event": "payment.success",
  "data": {
    "paymentId": "PAY-12345",
    "orderId": "ORDER-987",
    "amount": 450,
    "currency": "TRY",
    "status": "completed"
  }
}

Buradaki temel fark şu:

Klasik API çağrısında istemci genellikle bilgiyi istediği zaman talep eder.

Webhook yaklaşımında ise olay gerçekleştiğinde ilgili sistem bildirim gönderir.

Önemli: Webhook bildirimi geldi diye ödeme doğrudan başarılı kabul edilmemelidir. Bildirimin imzası, kaynağı ve işlem kimliği gibi bilgiler doğrulanmalıdır. Tekrarlanan bildirimler de güvenli biçimde ele alınmalıdır.

API Performansı Neden Önemlidir?

Diyelim ki çok güzel bir uygulama geliştirdin.

Tasarımı harika.

Renkler uyumlu.

Animasyonlar akıcı.

Ama kullanıcı ana sayfayı açtığında verilerin yüklenmesi 10 saniye sürüyor.

Kullanıcının göreceği şey güzel tasarım değil, bekleme ekranı olur.

API performansı, uygulamanın kullanıcıya ne kadar hızlı ve kararlı bir deneyim sunduğunda önemli rol oynar.

Peki API neden yavaş olabilir?

Bunun birçok nedeni olabilir.

Örneğin bir sayfa 20 öğrenci gösterecek.

Ama backend veritabanından 20 öğrenci yerine 20 bin öğrencinin bütün kayıtlarını getiriyor.

Üstelik her öğrenci için ayrı ayrı ek veritabanı sorguları gerçekleştiriliyor.

Böyle bir yapı hem veritabanına gereksiz yük bindirebilir hem de veri aktarımını artırabilir.

Bunun çözümü nedir?

İhtiyaca göre çeşitli teknikler kullanabiliriz.

Sayfalama (Pagination): Binlerce kaydı tek seferde göndermek yerine belirli sayıda kaydı getiririz.

Örneğin:

GET /api/ogrenciler?page=1&limit=20 HTTP/1.1
Host: ornek.com

Önbellekleme (Caching): Sık kullanılan ve uygun koşullarda yeniden kullanılabilecek sonuçları geçici olarak saklayabiliriz.

Veritabanı optimizasyonu: Gereksiz sorguları azaltabilir, uygun indeksler kullanabiliriz.

İstek sınırlandırma: Bir kullanıcının veya istemcinin belirli sürede gereğinden fazla işlem yapmasını önleyebiliriz.

Doğru veri seçimi: Frontend'in ihtiyaç duymadığı alanları her istekte göndermemeye dikkat edebiliriz.

Örneğin öğrenci listesinde yalnızca ad, soyad ve sınıf gösteriyorsan bütün öğrenci geçmişini göndermek çoğu zaman gerekli değildir.

Ama bunların her biri gerçek ihtiyaçlara göre değerlendirilmelidir.

Çok küçük bir proje için gereksiz karmaşık önbellek ve dağıtık sistem mimarileri kurmak da geliştirme sürecini zorlaştırabilir.

İyi performans yalnızca en fazla teknolojiyi kullanmak değil, doğru yerde doğru çözümü seçmektir.

API Hatası Olduğunda Uygulama Ne Yapmalı?

Şimdi gerçek hayattan küçük bir senaryo düşün.

Bir mobil uygulamada yeni görev oluşturdun.

“Kaydet” butonuna bastın.

Tam o anda internet bağlantın kesildi.

Uygulama ne yapmalı?

Hiçbir şey olmamış gibi davranması doğru değil.

Kullanıcıya anlaşılır bir hata mesajı göstermesi gerekir.

Ancak burada daha ilginç bir konu var.

İstek aslında sunucuya ulaşmış ve görev kaydedilmiş olabilir. Sadece yanıt kullanıcıya dönememiş olabilir.

Kullanıcı tekrar “Kaydet” butonuna bastığında aynı görev ikinci defa oluşabilir.

İşte buna benzer durumlar API tasarımında dikkat edilmesi gereken gerçek problemlerdir.

Özellikle ödeme ve sipariş gibi kritik işlemlerde tekrar gönderilen isteklerin aynı işlemi yanlışlıkla ikinci kez gerçekleştirmemesi gerekir.

Bu nedenle bazı sistemlerde idempotency key adı verilen işlem anahtarlarından yararlanılır.

Örnek:

POST /api/odemeler HTTP/1.1
Host: ornek.com
Content-Type: application/json
Idempotency-Key: islem-abc-123

{
  "orderId": "ORDER-987",
  "amount": 450,
  "currency": "TRY"
}

Basitçe söylersek: Aynı işlem yanlışlıkla tekrar gönderildiğinde sistemin gereksiz ikinci işlem oluşturmamasını sağlamaya yardımcı olur.

Tabii yalnızca header göndermek yeterli değildir. Sunucunun bu anahtarı uygun şekilde saklaması, karşılaştırması ve tekrar gelen istekleri doğru yönetmesi gerekir.

Ayrıca uygulamanın makul zaman aşımı, gerektiğinde kontrollü tekrar deneme ve açık hata mesajları sunması kullanıcı deneyimi için önemlidir.

API Geliştirmek Zor mu?

Bu sorunun cevabı biraz ne yapmak istediğine bağlı.

Az önce birkaç satır kodla çalışan küçük bir API geliştirdik.

Gördüğün gibi temel bir API yazmak düşündüğün kadar zor değil.

Ama gerçek bir projede işler büyüdükçe yeni ihtiyaçlar ortaya çıkar.

Örneğin:

Bir öğrenci sistemi geliştiriyorsun.

Öğrenciler yalnızca kendi bilgilerini görebilmeli.

Öğretmenler yalnızca kendilerine bağlı öğrencileri yönetebilmeli.

Kurum yöneticileri kendi kurumlarına ait raporları görebilmeli.

Sistem yöneticileri ise daha kapsamlı yönetim yetkilerine sahip olmalı.

Bir de dosya yükleme, bildirim, ödeme, mesajlaşma ve yapay zekâ özellikleri eklediğini düşün.

Artık mesele yalnızca bir API adresi yazmak değil.

Veritabanı tasarımı, rol yönetimi, güvenlik, performans, hata yönetimi ve sürdürülebilir yazılım mimarisi gibi konular da önem kazanır.

API geliştirme süresi ne kadar?

Çok basit bir örnek API birkaç saat içinde geliştirilebilir.

Ancak gerçek bir projede güvenlik kontrolleri, veritabanı işlemleri, dokümantasyon, testler ve entegrasyonlar zaman gerektirir.

Küçük bir entegrasyon birkaç günlük çalışma olabilirken kapsamlı bir backend sistemi haftalar veya daha uzun sürebilir.

Bu süreler kesin değildir. Projenin ihtiyaçlarına ve mevcut altyapıya göre değişir.

API Kullanmak Ücretli mi?

Burada iki farklı durumu birbirinden ayırmamız gerekiyor.

Birincisi kendi API'ni geliştirmek.

İkincisi başka bir şirketin API hizmetini kullanmak.

Kendi API'ni geliştirirken yazılımı çalıştıracağın sunucunun, veritabanının ve diğer altyapı bileşenlerinin maliyetleri olabilir.

Başka bir şirketin API'sini kullanıyorsan o şirketin fiyatlandırma modeli geçerli olur.

Bazı API'ler belirli kullanım sınırlarına kadar ücretsizdir.

Bazılarında aylık abonelik bulunur.

Bazılarında ise kullanılan işlem, veri miktarı, istek sayısı veya yapay zekâ token tüketimine göre ücretlendirme yapılır.

Örneğin yapay zekâ API'si kullanan bir uygulamada 100 kullanıcının günlük yaptığı işlem sayısıyla 10 bin kullanıcının yaptığı işlemler aynı maliyeti oluşturmayacaktır.

Bu nedenle API entegrasyonlarında yalnızca başlangıç geliştirme maliyetini değil, devam eden kullanım maliyetlerini de hesaba katmak gerekir.

API maliyetini etkileyen faktörler

• Günlük ve aylık istek sayısı.

• Gönderilen ve alınan veri miktarı.

• Kullanılan harici servislerin fiyatlandırması.

• Sunucu ve veritabanı kaynakları.

• Kullanıcı sayısı ve eşzamanlı işlem yükü.

• Güvenlik, bakım ve izleme ihtiyaçları.

• Entegrasyonun karmaşıklığı.

• Üçüncü taraf servisin kullanım kotaları.

Özellikle yoğun kullanılan projelerde bu maliyetleri en baştan değerlendirmek ileride sürprizlerle karşılaşma riskini azaltır.

Supabase ve Firebase Kullanıyorsak Yine API Yazmamız Gerekir mi?

Güzel bir soru.

Çünkü günümüzde birçok geliştirici backend altyapısının tamamını sıfırdan yazmak yerine hazır servislerden yararlanıyor.

Örneğin Supabase ve Firebase; kimlik doğrulama, veri saklama ve çeşitli backend hizmetleri sunar.

Bu servislerin kendi SDK'ları ve API mekanizmaları vardır.

Böylece geliştirici bazı işlemleri sıfırdan bir REST API hazırlamadan gerçekleştirebilir.

Mesela Supabase kullanarak uygun yetkilere sahip bir istemciden veri sorgulayabilir, kullanıcı giriş akışlarını yönetebilir veya gerektiğinde sunucu tarafında özel fonksiyonlar oluşturabilirsin.

Basit bir Supabase JavaScript örneği düşünelim:

import { createClient } from "@supabase/supabase-js";

const supabaseUrl = "https://projeniz.supabase.co";
const supabaseAnonKey = "PUBLIC_PUBLISHABLE_KEY";

const supabase = createClient(
  supabaseUrl,
  supabaseAnonKey
);

// Öğrencileri listele
async function ogrencileriGetir() {
  const { data, error } = await supabase
    .from("ogrenciler")
    .select("id, ad, sinif")
    .limit(20);

  if (error) {
    console.error("Veri alınamadı:", error.message);
    return;
  }

  console.log("Öğrenciler:", data);
}

Bu örnekte doğrudan kendi Express API'mizi yazmadık.

Supabase'in sunduğu istemci kütüphanesinden yararlandık.

Ancak bu, veritabanının herkese açık olması gerektiği anlamına gelmez. İstemciden yapılan sorguların güvenliği, Supabase tarafındaki kimlik doğrulama ve Row Level Security politikalarıyla sağlanmalıdır.

Firebase tarafında da benzer şekilde yönetilen hizmetlerden ve sunucu tarafı fonksiyonlardan yararlanabilirsin.

Ama bu, bütün iş mantığının doğrudan frontend içine yerleştirilmesi gerektiği anlamına gelmez.

Özellikle ödeme, gizli servis anahtarları, karmaşık iş kuralları ve hassas verilerin işlendiği operasyonlarda sunucu tarafı kontrolleri önemini korur.

Dolayısıyla soru şu değil:

“API yazmadan uygulama geliştirebilir miyim?”

Asıl soru:

“Bu uygulamanın hangi işlemlerini yönetilen servislerle, hangilerini kendi backend mantığımla gerçekleştirmeliyim?”

Doğru cevap her projenin ihtiyaçlarına göre değişir.

İyi Bir API Nasıl Tasarlanır?

Buraya kadar API'nin ne olduğunu, nasıl çalıştığını ve neden kullanıldığını gördük.

Peki iyi tasarlanmış bir API'nin özellikleri nelerdir?

Öncelikle anlaşılır olmalı.

Bir geliştirici /api/ogrenciler adresini gördüğünde bu kaynağın öğrencilerle ilgili olduğunu anlayabilmeli.

İkinci olarak tutarlı olmalı.

Bir yerde GET ile verileri listeliyorsan başka yerde benzer bir işlemi tamamen farklı kurallarla tasarlamamalısın.

Üçüncü olarak güvenli olmalı.

Kimlik doğrulama, yetki kontrolü, veri doğrulama ve gizli bilgilerin korunması önemlidir.

Dördüncü olarak hata yönetimi düzgün olmalı.

Kullanıcı yanlış bilgi gönderdiğinde veya sunucu bir sorun yaşadığında bunu anlaşılır biçimde ifade edebilmelidir.

Beşinci olarak genişletilebilir olmalı.

Bugün 50 kullanıcıya hizmet veren sistem, yarın 5 bin kullanıcıya hizmet verdiğinde bütün yazılımı sıfırdan geliştirmek zorunda kalmak istemezsin.

Bu nedenle API tasarımında modülerlik, test edilebilirlik, performans ve veri modeli gibi konular da değerlendirilmelidir.

Bir de API dokümantasyonu meselesi var.

Diyelim ki uygulamanı başka bir yazılımcı geliştirmeye devam edecek.

O kişinin hangi adresin ne yaptığını, hangi bilgileri beklediğini ve nasıl yanıt verdiğini anlayabilmesi gerekir.

İşte bunun için API dokümantasyonu hazırlanır.

OpenAPI gibi standartlar ve Swagger UI gibi araçlar bu süreci kolaylaştırabilir.

İyi hazırlanmış dokümantasyon, geliştirme sürecinde önemli zaman kazandırabilir.

API Entegrasyonu Yaptırmadan Önce Nelere Dikkat Edilmeli?

Diyelim ki bir işletme sahibisin ve web sitene ödeme, harita, kargo takip veya yapay zekâ özelliği ekletmek istiyorsun.

Burada yalnızca “Bu özelliği ekleyebilir miyiz?” sorusunu sormak yeterli değil.

Şunları da değerlendirmek gerekir:

Servis gerçekten ihtiyaçlarını karşılıyor mu? Her API aynı özellikleri sunmaz. Servis sağlayıcının dokümantasyonunu ve sınırlarını incelemek gerekir.

Kullanım maliyeti ne olacak? Başlangıçta ücretsiz görünen bir servis, kullanıcı sayısı arttıkça ücretli hale gelebilir.

Veriler nerede işlenecek? Özellikle kişisel verilerin kullanıldığı sistemlerde veri güvenliği, saklama koşulları ve ilgili mevzuat dikkate alınmalıdır.

Servis geçici olarak çalışmazsa ne olacak? Kritik işlemler için hata yönetimi ve alternatif süreçler planlanmalıdır.

İleride servis değiştirmek mümkün mü? Entegrasyonu uygun şekilde soyutlamak, gelecekte başka sağlayıcıya geçmeyi kolaylaştırabilir.

Kısacası doğru API seçimi yalnızca teknik bir tercih değil, aynı zamanda işletmenin sürdürülebilirliğini etkileyen bir karardır.

Bir Yazılım Projesinde API'yi Kim Geliştirir?

Küçük projelerde aynı geliştirici hem frontend hem de backend tarafıyla ilgilenebilir.

Bu kişilere genellikle Full-Stack Developer denir.

Daha büyük ekiplerde ise backend geliştiriciler, frontend geliştiriciler, mobil uygulama geliştiriciler ve sistem mimarları farklı sorumluluklar üstlenebilir.

Örneğin backend geliştirici API'yi ve iş kurallarını hazırlar.

Frontend geliştirici API'den gelen bilgileri kullanıcıya uygun biçimde gösterir.

Mobil geliştirici de aynı API'yi Android veya iOS uygulamasına entegre edebilir.

Böylece farklı platformlar, uygun tasarlanmış ortak bir backend altyapısını paylaşabilir.

Bu yaklaşım hem geliştirme sürecini kolaylaştırabilir hem de belirli iş kurallarının tek noktadan yönetilmesine yardımcı olabilir.

API Entegrasyonu ve Özel Yazılım Geliştirme

Şimdi bu konunun gerçek bir yazılım projesinde neden önemli olduğuna gelelim.

Bir işletmenin yalnızca tanıtım sitesi olabilir.

Başka bir işletmenin ise kullanıcı kayıtları, yönetim paneli, siparişleri, ödemeleri ve mobil uygulaması bulunabilir.

Bu iki projenin altyapı ihtiyaçları aynı değildir.

Örneğin özel bir yönetim paneli geliştirirken kullanıcıların yetkilerini, verilerin nasıl saklanacağını ve sistemin diğer yazılımlarla nasıl iletişim kuracağını birlikte planlamak gerekir.

Ben Mühendisiniz olarak web sitesi, mobil uygulama ve özel yazılım geliştirme süreçlerinde bu tür ihtiyaçları projenin kapsamına göre değerlendiriyoruz.

Bir uygulamaya ödeme sistemi eklemek, mevcut bir yazılımı farklı servislerle konuşturmak veya sıfırdan backend mimarisi oluşturmak gerektiğinde önce ihtiyaçları ve mevcut altyapıyı incelemek önemli.

Çünkü bazen hazır bir API entegrasyonu yeterli olurken bazen daha kapsamlı bir özel yazılım geliştirme sürecine ihtiyaç duyulabilir.

Amaç yalnızca çalışan bir özellik oluşturmak değil; güvenli, yönetilebilir ve ileride geliştirilebilir bir sistem kurmaktır.

Sonuç: API, Yazılımların Birbirini Anlamasını Sağlayan Köprülerden Biri

Başlangıçta yalnızca bir yemek siparişi örneğiyle yola çıktık.

Sonra kullanıcı girişinin nasıl çalıştığını, frontend ile backend'in nasıl haberleştiğini, HTTP isteklerini, JSON verilerini ve gerçek bir API'nin nasıl yazıldığını gördük.

Şimdi tekrar ilk sorumuza dönelim:

API nedir?

API, yazılımların belirlenmiş kurallar üzerinden veri alışverişi yapmasını veya birbirlerinin sunduğu işlevlerden yararlanmasını sağlayan arayüzdür.

Mobil uygulamalardan web sitelerine, ödeme sistemlerinden yapay zekâ servislerine kadar çok geniş bir alanda kullanılır.

API kavramını anlamak, modern yazılımların nasıl çalıştığını anlamanın önemli adımlarından biridir.

Çünkü artık yalnızca tek başına çalışan programlar geliştirmiyoruz.

Birbirine bağlanan, veri paylaşan, başka servislerden yararlanan ve aynı kullanıcıya farklı cihazlar üzerinden hizmet veren sistemler oluşturuyoruz.

Ve bütün bu yapının arkasında iyi düşünülmüş bir iletişim mimarisi bulunuyor.

Bir dahaki sefere bir uygulamada “Giriş Yap”, “Ödeme Yap” veya “Kaydet” butonuna bastığında, ekranda gördüğün şeyin arkasında hangi sistemlerin konuştuğunu düşün.

Belki de artık o birkaç saniyelik yükleme animasyonuna eskisinden çok daha farklı bakacaksın.

Sık Sorulan Sorular (SSS)

API nedir, ne işe yarar?

API, bir yazılımın başka bir yazılımın verilerine veya işlevlerine tanımlanmış kurallar üzerinden erişmesini sağlar. Web sitelerinde, mobil uygulamalarda ve farklı sistemlerin entegrasyonunda yaygın olarak kullanılır.

API ile backend aynı şey mi?

Hayır. Backend, uygulamanın sunucu tarafındaki iş mantığını ve işlemlerini yöneten bölümdür. API ise backend'in belirli işlevlerini diğer sistemlere sunan bir arayüz olabilir.

API ile veritabanı arasındaki fark nedir?

Veritabanı bilgileri saklar ve yönetir. API ise uygun yetki ve kurallarla bu bilgilere erişmek veya işlem yapmak için kullanılabilir.

API kullanmak için programlama bilmek gerekir mi?

API'yi kullanan normal kullanıcıların programlama bilmesi gerekmez. API geliştirmek ve yazılıma entegre etmek içinse ilgili programlama dili, HTTP ve veri formatları hakkında bilgi sahibi olmak yararlıdır.

REST API nedir?

REST API, REST mimari ilkelerini izleyen bir web API yaklaşımıdır. Genellikle HTTP yöntemleri ve kaynak adresleri üzerinden işlemleri gerçekleştirir.

API geliştirmek ne kadar sürer?

Basit bir örnek birkaç saat içinde hazırlanabilir. Gerçek projelerde süre; özellikler, veritabanı, güvenlik, test ve entegrasyonların kapsamına göre değişir.

API kullanmak ücretsiz mi?

Bazı API servisleri ücretsiz planlar sunar, bazıları ücretlidir. Kullanım sayısı, veri miktarı ve sunulan özellikler maliyeti etkileyebilir.

API güvenli midir?

API'nin güvenliği doğru tasarlanmasına ve yapılandırılmasına bağlıdır. Kimlik doğrulama, yetkilendirme, HTTPS, veri doğrulama ve erişim sınırları gibi önlemler gerekir.

Mobil uygulama ve web sitesi aynı API'yi kullanabilir mi?

Evet. Uygun şekilde tasarlanmış bir backend API'si hem web sitesi hem de mobil uygulama tarafından kullanılabilir. Bu sayede farklı platformlarda ortak veriler ve iş kuralları yönetilebilir.

API anahtarı nedir?

API anahtarı, bazı servislerin uygulama veya geliştirici erişimini tanımlamak için kullandığı değerdir. Gizli API anahtarları korunmalı ve güvenli ortamlarda saklanmalıdır.

Yapay zekâ uygulamaları API kullanır mı?

Evet. Birçok uygulama, yapay zekâ modellerine API üzerinden istek göndererek metin oluşturma, görsel yorumlama veya başka işlemler gerçekleştirebilir.

API olmadan yazılım geliştirilir mi?

Evet. Örneğin yalnızca cihaz içinde çalışan basit bir hesap makinesinin web API kullanması gerekmez. Ancak farklı sistemlerle iletişim ve merkezi veri yönetimi gerektiğinde API'ler önemli hale gelir.