DEV Community

Cover image for Mock API Nedir? Açık Bir Açıklama
Tobias Hoffmann
Tobias Hoffmann

Posted on • Originally published at apidog.com

Mock API Nedir? Açık Bir Açıklama

Bir sahte API (mock API), gerçek API ile aynı istekleri kabul eden ve aynı biçimde yanıt döndüren, ancak arkasında gerçek veritabanı, iş mantığı veya canlı servis bulunmayan API'dir. Yanıtlar sizin önceden tanımladığınız kurallardan gelir; bu sayede gerçek servis hazır olmadan önce istemci geliştirebilir, test yazabilir ve hata senaryolarını güvenli şekilde çalıştırabilirsiniz.

Apidog'u bugün deneyin

Sahte API pratikte nasıl çalışır?

Bir sahte API'yi en basit haliyle şu şekilde düşünebilirsiniz:

  1. İstek gelir.
  2. Mock sunucu isteği rota, metod, parametre veya header'a göre eşleştirir.
  3. Eşleşen yanıtı döndürür.

Örneğin gerçek API'niz şu endpoint'i sunacaksa:

GET /users/123
Enter fullscreen mode Exit fullscreen mode

Mock API aynı endpoint için önceden tanımlı bir JSON döndürebilir:

{
  "id": "123",
  "name": "Ayşe Yılmaz",
  "email": "ayse@example.com"
}
Enter fullscreen mode Exit fullscreen mode

İstemci tarafında değişen tek şey genellikle temel URL'dir:

const API_BASE_URL = "https://mock.example.com";
// const API_BASE_URL = "https://api.example.com";

const res = await fetch(`${API_BASE_URL}/users/123`);
const user = await res.json();

console.log(user.name);
Enter fullscreen mode Exit fullscreen mode

Kod mock API'nin sahte olduğunu bilmez. Gerçek API hazır olduğunda temel URL'yi değiştirirsiniz ve aynı istemci canlı servisle konuşur.

Uygulamalı bir örnek için test için bir API'yi sahteleme rehberine bakabilirsiniz.

Bir sahte API'nin üç parçası

Bir mock API oluştururken şu üç şeyi net tanımlamanız gerekir:

1. Arayüz

Gerçek API ile aynı olmalıdır:

  • HTTP metodu: GET, POST, PUT, DELETE
  • Rota: /users/{id}
  • Parametreler: path, query, body
  • Header'lar: Authorization, Content-Type vb.

Örnek OpenAPI parçası:

paths:
  /users/{id}:
    get:
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: Kullanıcı bulundu
Enter fullscreen mode Exit fullscreen mode

2. Yanıt tanımı

Mock API'nin döndüreceği şunları tanımlarsınız:

  • HTTP durum kodu
  • Response body
  • Header'lar

Örnek:

HTTP/1.1 200 OK
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode 
{
  "id": "123",
  "name": "Ayşe Yılmaz",
  "email": "ayse@example.com"
}
Enter fullscreen mode Exit fullscreen mode

3. Eşleştirme mantığı

Mock sunucu hangi isteğe hangi yanıtı vereceğini bilmelidir.

Basit eşleştirme:

GET /users/123 -> 200 user response
Enter fullscreen mode Exit fullscreen mode

Koşullu eşleştirme:

GET /users/404 -> 404 not found
GET /users/123 -> 200 user response
Authorization yoksa -> 401 unauthorized
Enter fullscreen mode Exit fullscreen mode

Bu yapı sayesinde tek bir mock endpoint hem başarılı akışı hem de hata akışlarını test etmenizi sağlar.

Sahte API ne değildir?

Sahte API'yi şu kavramlarla karıştırmamak gerekir:

Kavram Farkı
Önbellek Cache gerçek yanıtları saklar; mock API yanıtları sizin tanımınızdan üretir.
Sanal ortam Sanal ortam sınırlı da olsa gerçek mantık çalıştırabilir; mock API genellikle yalnızca tanımlı yanıt döndürür.
Hazırlık ortamı Staging, gerçek sistemin dağıtılmış halidir; mock API daha hafiftir ve gerçek servis çalıştırmaz.

Mock API'nin amacı gerçek sistemi kanıtlamak değil, gerçek sistem yokken veya kullanılması riskliyken geliştirme ve test yapmanızı sağlamaktır.

Mock ve Stub farkı

Günlük API geliştirme konuşmalarında "mock" ve "stub" çoğu zaman aynı anlamda kullanılır. Ancak test terminolojisinde fark vardır.

Stub

Stub yalnızca hazır yanıt döndürür.

function getUserStub() {
  return {
    id: "123",
    name: "Ayşe"
  };
}
Enter fullscreen mode Exit fullscreen mode

Stub için önemli olan çağrının nasıl yapıldığı değil, hangi verinin döndüğüdür.

Mock

Mock ise çağrıyı doğrulayabilir:

  • Çağrıldı mı?
  • Kaç kez çağrıldı?
  • Hangi argümanlarla çağrıldı?

Örnek:

expect(apiClient.getUser).toHaveBeenCalledWith("123");
expect(apiClient.getUser).toHaveBeenCalledTimes(1);
Enter fullscreen mode Exit fullscreen mode

Kısa özet:

Tür Ne yapar?
Stub Yanıt döndürür.
Mock Yanıt döndürür ve etkileşimi izler/doğrular.

API geliştirmede kullanılan "sahte API" genellikle HTTP üzerinden çalışan stub davranışına yakındır. Bazı araçlar buna çağrı doğrulama özellikleri de ekleyebilir.

Daha geniş terminoloji için doğrulama ve tasdik arasındaki farka bakabilirsiniz.

Sahte API ve gerçek sunucu karşılaştırması

Gerçek sunucu ile mock sunucu aynı endpoint'i sunabilir ve aynı JSON'u döndürebilir. Fark, endpoint'in arkasında ne olduğudur.

Sahte API Gerçek sunucu
Uç noktanın arkasında Önceden tanımlanmış yanıtlar Canlı mantık ve veritabanı
Yanıt kaynağı Sizin yazdığınız kurallar İstek başına hesaplanır
Veri Sabit veya üretilmiş Gerçek ve kalıcı
Yan etkiler Yok Yazma işlemleri, ücretlendirme, e-posta
Hız Hızlı ve sabit Yüke göre değişir
Doğruluk Tanımladığınız sözleşmeyle sınırlı Gerçek davranışı gösterir

Gerçek sunucu sistemin gerçekten çalıştığını kanıtlar. Ancak gerçek yan etkiler oluşturabilir:

  • Test sırasında e-posta gönderebilir.
  • Gerçek ödeme akışını tetikleyebilir.
  • Veritabanında kalıcı kayıt oluşturabilir.
  • Ağ veya ortam sorunları nedeniyle kararsız testlere yol açabilir.

Mock API ise hızlı, tahmin edilebilir ve yan etkisizdir. Bu yüzden geliştirme, prototipleme ve birçok test senaryosu için uygundur.

Ancak mock API gerçek mantığı çalıştırmadığı için yanlış da olabilir. Bu nedenle yalnızca mock'a güvenmeyin; kritik sözleşme ve uçtan uca testleri gerçek sunucuya karşı da çalıştırın.

Bu denge sahte sunucuya karşı gerçek sunucu rehberinde daha ayrıntılı ele alınmıştır.

Statik ve dinamik sahte API

Mock API yanıtları iki şekilde oluşturulabilir.

Statik mock

Statik mock her istekte aynı yanıtı döndürür.

{
  "id": "user_1001",
  "name": "Ayşe Yılmaz",
  "email": "ayse@example.com"
}
Enter fullscreen mode Exit fullscreen mode

Şu durumlarda kullanışlıdır:

  • Birim testlerde belirli bir değere assertion yazarken
  • Snapshot testlerinde
  • Aynı girdiye aynı çıktıyı beklediğiniz senaryolarda

Örnek test:

expect(user.id).toBe("user_1001");
expect(user.email).toBe("ayse@example.com");
Enter fullscreen mode Exit fullscreen mode

Dezavantajı, gerçek dünyadaki veri çeşitliliğini yakalayamamasıdır. Tek bir sabit payload, boş liste, uzun string, null değer veya farklı tarih formatı gibi sorunları ortaya çıkarmayabilir.

Dinamik mock

Dinamik mock her istekte veri üretebilir.

Örneğin sabit id yerine her çağrıda yeni UUID dönebilir:

{
  "id": "7f1d9e90-4f3a-4d9e-9b6a-01c2b3a4d5e6",
  "name": "Mehmet Kaya",
  "email": "mehmet.kaya@example.com",
  "created_at": "2026-05-22T10:30:00Z"
}
Enter fullscreen mode Exit fullscreen mode

Dinamik mock'lar genellikle Faker.js gibi veri üretim araçlarıyla çalışır.

Örnek fikir:

import { faker } from "@faker-js/faker";

const user = {
  id: faker.string.uuid(),
  name: faker.person.fullName(),
  email: faker.internet.email(),
  created_at: faker.date.recent().toISOString()
};
Enter fullscreen mode Exit fullscreen mode

Dinamik mock şu durumlarda daha uygundur:

  • UI'nın farklı veri uzunluklarında nasıl davrandığını görmek
  • Demo verisi üretmek
  • Boş, uzun, rastgele veya beklenmeyen değerlere karşı dayanıklılığı test etmek
  • Fuzz-style testlere yaklaşmak

Dezavantajı, her değer değişebildiği için doğrudan eşitlik assertion'ları yazmanın zorlaşmasıdır.

Bunun yerine tip ve format kontrol edin:

expect(user.id).toEqual(expect.any(String));
expect(user.email).toContain("@");
expect(Date.parse(user.created_at)).not.toBeNaN();
Enter fullscreen mode Exit fullscreen mode

Koşullu mock ile hata senaryosu test etme

Mock API'nin en faydalı olduğu alanlardan biri hata senaryolarını kontrollü üretmektir.

Örneğin:

GET /orders/123  -> 200 OK
GET /orders/404  -> 404 Not Found
GET /orders/500  -> 500 Internal Server Error
Authorization yoksa -> 401 Unauthorized
Enter fullscreen mode Exit fullscreen mode

Bu sayede gerçek sunucuyu bozmanıza gerek kalmadan istemci tarafındaki hata yönetimini test edebilirsiniz.

Örnek frontend kontrolü:

async function getOrder(id) {
  const res = await fetch(`${API_BASE_URL}/orders/${id}`);

  if (res.status === 404) {
    return { error: "Sipariş bulunamadı" };
  }

  if (!res.ok) {
    return { error: "Beklenmeyen bir hata oluştu" };
  }

  return res.json();
}
Enter fullscreen mode Exit fullscreen mode

Test senaryoları:

test("404 durumunda kullanıcıya hata döner", async () => {
  const result = await getOrder("404");

  expect(result.error).toBe("Sipariş bulunamadı");
});
Enter fullscreen mode Exit fullscreen mode

Gerçek sunucu sağlıklı çalışırken bu tür hataları talep üzerine üretmek zor olabilir. Mock API burada kontrollü bir test yüzeyi sağlar.

Sahte API geliştirme sürecinde nerede kullanılır?

Mock API'yi özellikle şu aşamalarda kullanabilirsiniz.

1. Backend hazır değilken frontend geliştirme

Backend ekibi endpoint'i henüz tamamlamamış olabilir. Yine de frontend ekibi sözleşmeye göre geliştirmeye başlayabilir.

Örnek sözleşme:

GET /products
Enter fullscreen mode Exit fullscreen mode

Yanıt:

[
  {
    "id": "p_1",
    "name": "Kablosuz Klavye",
    "price": 1299
  }
]
Enter fullscreen mode Exit fullscreen mode

Frontend bu sözleşmeye göre listeleme ekranını geliştirir. Backend hazır olduğunda aynı endpoint gerçek sunucuya bağlanır.

2. Kararlı test ortamı oluşturma

Gerçek servisler bazen yavaş, pahalı veya kararsız olabilir. Mock API ile testleri dış bağımlılıklardan izole edebilirsiniz.

Örnek kullanım:

CI testleri -> mock API
Sözleşme testleri -> gerçek API
Uçtan uca kritik akışlar -> gerçek API
Enter fullscreen mode Exit fullscreen mode

Bu ayrım testlerin hem hızlı hem de güvenilir kalmasını sağlar.

3. Hata durumlarını güvenli test etme

Gerçek ödeme sisteminde 500 hatası üretmek veya bilinçli olarak başarısız ücretlendirme yapmak risklidir. Mock API ile bu durumları güvenli şekilde simüle edebilirsiniz.

Örnek:

POST /payments/success -> 200
POST /payments/declined -> 402
POST /payments/error -> 500
Enter fullscreen mode Exit fullscreen mode

4. Demo ve prototip hazırlama

Canlı servise bağımlı olmayan bir demo, sunum sırasında daha tahmin edilebilirdir. Mock API ile aynı verileri her seferinde gösterebilir veya dinamik demo verisi üretebilirsiniz.

Bu senaryolar API sahteleme kullanım durumları rehberinde daha ayrıntılı incelenmiştir.

Mock API'nin yanlış hale gelmesini nasıl engellersiniz?

Mock API'nin en büyük riski sapmadır.

Gerçek API değişir:

{
  "full_name": "Ayşe Yılmaz"
}
Enter fullscreen mode Exit fullscreen mode

Ama mock hâlâ eski alanı döndürür:

{
  "name": "Ayşe Yılmaz"
}
Enter fullscreen mode Exit fullscreen mode

Bu durumda testleriniz geçebilir, ancak gerçek entegrasyon bozulur.

Bunu önlemek için mock API'yi elle yazılmış bağımsız bir kopya gibi değil, API sözleşmesinden türetilmiş bir çıktı gibi ele alın.

Pratik yaklaşım:

  1. API sözleşmesini OpenAPI veya benzer bir şemada tanımlayın.
  2. Mock endpoint'leri bu sözleşmeden üretin.
  3. Dokümantasyon, mock ve testleri aynı kaynaktan besleyin.
  4. Gerçek API'ye karşı düzenli sözleşme testleri çalıştırın.

Örnek kaynak sözleşme:

components:
  schemas:
    User:
      type: object
      required:
        - id
        - email
      properties:
        id:
          type: string
        email:
          type: string
          format: email
        created_at:
          type: string
          format: date-time
Enter fullscreen mode Exit fullscreen mode

Bu sözleşmeden üretilen mock, alan adları ve tiplerle uyumlu kalır. Sözleşme değiştiğinde mock da yeniden oluşturulmalıdır.

Apidog bu modelle çalışır: API'yi bir kez tasarlarsınız; mock endpoint, dokümantasyon ve API sözleşme testi aynı kaynaktan beslenir. Tasarımdan mock'a akışı uçtan uca görmek için Apidog'u indirin.

Uygulama kontrol listesi

Bir mock API hazırlarken şu listeyi kullanabilirsiniz:

  • [ ] Gerçek API ile aynı rota ve HTTP metodlarını tanımlayın.
  • [ ] Başarılı yanıtları ekleyin.
  • [ ] 400, 401, 403, 404, 500 gibi hata yanıtlarını ekleyin.
  • [ ] Header ve query parametrelerine göre koşullu yanıtlar tanımlayın.
  • [ ] Statik ve dinamik veri ihtiyacını ayırın.
  • [ ] Mock verisini API sözleşmesinden üretmeye çalışın.
  • [ ] Gerçek API'ye karşı sözleşme testleri çalıştırın.
  • [ ] Frontend, backend ve QA ekiplerinin aynı sözleşmeyi kullandığından emin olun.

Sıkça sorulan sorular

Basitçe sahte API nedir?

Sahte API, gerçek API'yi taklit eden API'dir. Aynı rotaları açığa çıkarır ve aynı biçimde yanıt döndürür, ancak arkasında gerçek veritabanı veya iş mantığı yoktur. Yanıtlar önceden tanımlıdır.

Mock ile Stub arasındaki fark nedir?

Stub yalnızca hazır yanıt döndürür. Mock ise yanıt döndürmenin yanında çağrının doğru yapılıp yapılmadığını da doğrulayabilir. Kısaca: stub yanıtlar; mock yanıtlar ve izler.

Sahte API gerçek sunucudan nasıl farklıdır?

Sahte API önceden tanımlı yanıtlar döndürür ve yan etkisi yoktur. Gerçek sunucu gerçek mantığı çalıştırır, veritabanına erişir ve kalıcı değişiklikler yapabilir. Geliştirme ve güvenli testler için mock; gerçek davranışı kanıtlamak için gerçek sunucu kullanılır.

Statik mi dinamik mock mu kullanmalıyım?

Tekrarlanabilir ve assertion yazması kolay testler için statik mock kullanın. Gerçekçi, çeşitli ve değişken veriyle geliştirme veya demo yapmak için dinamik mock kullanın. Çoğu ekip ikisini birlikte kullanır.

Sahte API'nin yanlış hale gelmesini nasıl engellerim?

Mock API'yi elle yazılmış ayrı bir kopya olarak tutmayın. Gerçek API'nin kullandığı sözleşmeden veya şemadan üretin. Sözleşme değiştiğinde mock'u yeniden oluşturun ve gerçek API'ye karşı düzenli sözleşme testleri çalıştırın.

Top comments (0)