🔌 Frontend & Backend Nasıl Konuşur

Frontend & Backend Nasıl Konuşur: Frontend ile backend arasındaki konuşma, bir RESTORANDAKİ garson-mutfak ilişkisi gibidir: tarayıcı (garson) `/api/v1/bugs`'a bir istek götürür,

Frontend ile backend arasındaki konuşma, bir RESTORANDAKİ garson-mutfak ilişkisi gibidir: tarayıcı (garson) `/api/v1/bugs`'a bir istek götürür, sunucu (mutfak) JSON döner, JS bu JSON'u DOM'a (tabağa) dizer. Neden bir tester bu köprüyü bilmeli? Çünkü elementin ne zaman DOM'a geleceği tamamen bu konuşmanın hızına bağlıdır — ayrıca sayfanın NEREDE oluştuğu (tarayıcıda mı = CSR, sunucuda mı = SSR) locate zamanlamasını kökten değiştirir. Java analojisi: bu köprü `/api-testing` sayfasında öğrendiğin request/response sözleşmesinin frontend tarafından görünüşüdür — aynı Bug modeli, şimdi ekranda. QA bağlamında: "UI'da görünmüyor" dediğin bir bug'ın kökü frontend mi (render) yoksa backend mi (response) — bunu ayırt etmek Network panelini okumaktan geçer. Bu grup boyunca `/api-testing` sayfasına köprü kuracağız — syntax orada, "neden/ne zaman" burada.

🌐 E1. Tarayıcı → Sunucu: fetch/XHR, `/api/v1/bugs` İsteği

Bir `fetch`/XHR isteği göndermek, bir KARGO GÖNDERMEK gibidir: paketi (isteği) yola çıkarırsın, bir TAKİP NUMARASI (Network paneli satırı) alırsın ve paketin durumunu ("pending" → "delivered") bu numaradan izlersin. Peki neden tester bu paneli okumayı bilmeli? Çünkü "UI'da bir şey görünmüyor" dediğin bir bug'ın DevTools → Network'te tam olarak NEREDE tıkandığını (istek hiç gitmedi mi? sunucu 404/500 mü döndü? response boş mu geldi?) görmek, hatayı frontend'e mi backend'e mi atayacağını AYIRT eder. Java analojisi: eski `HttpURLConnection` (callback/blocking hissi veren XHR'ın atası) ile modern `HttpClient`/`CompletableFuture` (fetch'in Promise tabanlı yapısı) arasındaki fark gibi — API'ler değişse de temel HTTP mekaniği aynıdır. QA bağlamında: bu sayfa `fetch`/XHR SYNTAX'ını öğretmez (bkz. `/api-testing`, `/javascript`); burada öğrenilen, Network panelini bir TEŞHİS ARACI olarak okumaktır.

Adım Adım: Bir Tıklama Network Panelinde Nasıl Görünür?

Kullanıcı "New Bug" gönderir

JS, form verisini toplayıp `fetch('/api/v1/bugs', {method:'POST', body:...})` çağrısını tetikler.

İstek Network paneline düşer

DevTools → Network'te YENİ bir satır belirir: `POST /api/v1/bugs`, durumu "pending" (bekliyor).

Bu satır "pending" kaldığı sürece sunucu HENÜZ cevap vermedi — bu, GRUP D3'teki yarışın Network panelindeki karşılığıdır.

Status kodu ve response gelir

Satır "200" (veya 4xx/5xx) ile GÜNCELLENİR ve response sekmesinde JSON gövde görünür hale gelir.

Tester için köprü: `/api-testing`

Bu satırdaki method/status/gövde, `/api-testing` sayfasında öğrendiğin sözleşmenin frontend tarafından GÖRÜNÜŞÜDÜR — bug'ın frontend'de mi backend'de mi olduğunu Network panelinden ayırt edersin.

Bir tester "New Bug" formunu gönderiyor, Toast bildirimi hiç görünmüyor. DevTools → Network'te `POST /api/v1/bugs` satırını inceliyor ve status "(failed) net::ERR_CONNECTION_REFUSED" görüyor. Bu neyi işaret eder?