- Konu sahibi
- #1
Mock API, gerçek bir backend servisi hazır olmadan API varmış gibi davranan sahte veya simüle edilmiş API'dir. Uygulamanın beklediği istekleri alır, önceden tanımlanmış yanıtları döndürür ve frontend geliştirme, entegrasyon testi, demo hazırlama veya hata senaryolarını deneme amacıyla kullanılır. Gerçek veritabanına ve üretim servisine bağlı olmak zorunda değildir.
Örneğin ürün listeleme ekranınız henüz hazır olmayan bir e-ticaret API'sinden veri bekliyor olabilir. Frontend geliştiricisi, gerçek servis tamamlanana kadar
Frontend kodu bu yanıtı gerçek API'den geliyormuş gibi işler. Yanıt sözleşmesi tutarlıysa gerçek servise geçiş kolaylaşır; yine de kimlik doğrulama, çerez, CORS ve gerçek hata davranışları ayrıca sınanmalıdır. Yalnız adresi değiştirmenin her projede yeterli olduğu varsayılmamalıdır.
Mock API, gerçek API'nin sözleşmesini taklit eder. Bu sözleşmede endpoint yolu, HTTP metodu, istek gövdesi, parametreler, yanıt biçimi ve hata kodları bulunur. Bir istek geldiğinde mock sunucusu bu kurallara göre sabit, şablonlanmış veya dinamik bir yanıt üretir.
Mock API ile gerçek API arasındaki temel farkları karar verirken şu şekilde değerlendirebilirsiniz:
Mock hizmeti testler için kalıcı tutulabilir; fakat gerçek üretim iş mantığını, veritabanını veya yetkilendirmeyi doğruladığı anlamına gelmez. Fark, yalnız hizmetin çalıştığı süre değil hangi davranışları simüle ettiğidir.
Mock API özellikle şu durumlarda yararlıdır:
Mock yanıtını gerçek API'nin tüm davranışı sanmak en yaygın hatadır. Sabit veri; veritabanı sorgu hatalarını, gerçek yetkilendirme kurallarını, eşzamanlı güncellemeleri, ağ gecikmesini veya üretim performansını kendiliğinden test etmez. Bu nedenle mock testlerinden geçen uygulama, gerçek API ile ayrıca entegrasyon testine alınmalıdır.
Bir diğer hata, mock ile gerçek API’nin yanıt şemasında farklı alan isimleri kullanmasıdır. Örneğin mock yanıtında
Genellikle hayır. Mock API kontrollü geliştirme ve test içindir; gerçek kullanıcı verisi, kalıcı kayıt, güvenilir yetkilendirme ve iş kuralları gerekiyorsa gerçek backend kullanılmalıdır.
Bu adlar araç ve test yaklaşımına göre değişebilir; aralarında her projede geçerli “tek endpoint/çok endpoint” sınırı yoktur. Önemli olan hangi isteklerin eşleştirildiğini, hangi yanıtların döndüğünü ve etkileşim beklentilerinin doğrulanıp doğrulanmadığını açıkça tanımlamaktır.
Hemen silinmesi gerekmez. Otomatik test, demo ve hata senaryoları için korunabilir; ancak gerçek API sözleşmesi değiştiğinde mock tanımlarının güncel tutulması gerekir.
Örneğin ürün listeleme ekranınız henüz hazır olmayan bir e-ticaret API'sinden veri bekliyor olabilir. Frontend geliştiricisi, gerçek servis tamamlanana kadar
GET /api/products isteğine kurgusal ürün ve fiyatlarla aşağıdaki gibi sabit bir yanıt döndüren mock API kullanabilir:
Kod:
{
"data": [
{ "id": 1, "name": "Klavye", "price": 899 },
{ "id": 2, "name": "Fare", "price": 449 }
],
"page": 1,
"total": 2
}Frontend kodu bu yanıtı gerçek API'den geliyormuş gibi işler. Yanıt sözleşmesi tutarlıysa gerçek servise geçiş kolaylaşır; yine de kimlik doğrulama, çerez, CORS ve gerçek hata davranışları ayrıca sınanmalıdır. Yalnız adresi değiştirmenin her projede yeterli olduğu varsayılmamalıdır.
Mock API nasıl çalışır?
Mock API, gerçek API'nin sözleşmesini taklit eder. Bu sözleşmede endpoint yolu, HTTP metodu, istek gövdesi, parametreler, yanıt biçimi ve hata kodları bulunur. Bir istek geldiğinde mock sunucusu bu kurallara göre sabit, şablonlanmış veya dinamik bir yanıt üretir.
Mock API ile gerçek API arasındaki temel farkları karar verirken şu şekilde değerlendirebilirsiniz:
| Konu | Mock API | Gerçek API |
|---|---|---|
| Veri kaynağı | Sabit dosya, bellek veya senaryo | Veritabanı ve servisler |
| Amaç | Geliştirme ve test | Gerçek iş akışı ve üretim kullanımı |
| Bağımlılık | Backend hazır olmasa da çalışabilir | Gerçek işlevin gerektirdiği servisler ve erişim politikası gerekir |
| Gerçekçilik | Tanımlanan senaryolarla sınırlıdır | Gerçek veri ve kuralları kullanır |
Ne zaman kullanılmalı?
Mock API özellikle şu durumlarda yararlıdır:
- Frontend geliştirilirken backend ekibi henüz endpoint'i tamamlamadıysa.
- Başarılı yanıt, boş liste, yetkisiz erişim veya sunucu hatası gibi senaryolar kontrollü biçimde denenmek isteniyorsa.
- Demo, prototip veya otomatik test için değişmeyen veri gerekiyorsa.
- Gerçek servise yapılan isteklerin geliştirme sırasında gereksiz maliyet, kota veya veri değişikliği oluşturması istenmiyorsa.
Uygulamada izlenecek yol
- Önce gerçek API sözleşmesini belirleyin. Örneğin
GET /api/productsisteğinin hangi durum kodunu ve hangi JSON alanlarını döndüreceğini yazılı hale getirin. - Başarılı yanıtın yanında en az bir hata senaryosu tanımlayın. Örneğin ürün bulunamadığında
404, geçersiz oturumda401döndürün. - Mock endpoint'i frontend'in beklediği adresle aynı istek metodu, yol ve veri yapısında oluşturun.
- Uygulamanızı bu mock adrese bağlayıp yükleniyor, boş sonuç, hata ve tekrar deneme durumlarını kontrol edin.
- Gerçek API hazır olduğunda aynı istekleri gerçek sunucuya yönlendirin ve yanıt şemasını mock ile karşılaştırın.
Sık yapılan hatalar
Mock yanıtını gerçek API'nin tüm davranışı sanmak en yaygın hatadır. Sabit veri; veritabanı sorgu hatalarını, gerçek yetkilendirme kurallarını, eşzamanlı güncellemeleri, ağ gecikmesini veya üretim performansını kendiliğinden test etmez. Bu nedenle mock testlerinden geçen uygulama, gerçek API ile ayrıca entegrasyon testine alınmalıdır.
Bir diğer hata, mock ile gerçek API’nin yanıt şemasında farklı alan isimleri kullanmasıdır. Örneğin mock yanıtında
name, gerçek serviste product_name bulunuyorsa frontend geçiş sırasında kırılabilir. Mock verisini mümkün olduğunca gerçek sözleşmeye bağlı tutun ve değişiklik olduğunda iki tarafın şemasını birlikte güncelleyin.Sık sorulan sorular
Mock API üretim ortamında kullanılabilir mi?
Genellikle hayır. Mock API kontrollü geliştirme ve test içindir; gerçek kullanıcı verisi, kalıcı kayıt, güvenilir yetkilendirme ve iş kuralları gerekiyorsa gerçek backend kullanılmalıdır.
Mock API ile stub API aynı şey midir?
Bu adlar araç ve test yaklaşımına göre değişebilir; aralarında her projede geçerli “tek endpoint/çok endpoint” sınırı yoktur. Önemli olan hangi isteklerin eşleştirildiğini, hangi yanıtların döndüğünü ve etkileşim beklentilerinin doğrulanıp doğrulanmadığını açıkça tanımlamaktır.
Mock API gerçek backend hazır olduğunda silinmeli mi?
Hemen silinmesi gerekmez. Otomatik test, demo ve hata senaryoları için korunabilir; ancak gerçek API sözleşmesi değiştiğinde mock tanımlarının güncel tutulması gerekir.
