HTTP Nasıl Çalışır? Request ve Response Mantığı, Metotlar, Header, Body, Cookie ve Durum Kodları

Web üzerinde bir sayfa açtığınızda, bir forma veri gönderdiğinizde ya da bir API'den bilgi çektiğinizde arka planda neredeyse her şey HTTP ile gerçekleşir. HTTP, tarayıcı ile sunucu arasındaki iletişimin temel dilidir ve modern web'in omurgasını oluşturur. Bu iletişim modeli ilk bakışta basit görünse de, request, response, header, body, cookie ve durum kodları gibi bileşenler birlikte çalışarak oldukça güçlü bir yapı ortaya çıkarır.

Bu yazıda HTTP'nin çalışma mantığını en temel seviyeden başlayarak teknik açıdan derinlemesine inceleyeceğiz. Özellikle GET, POST, PUT, PATCH, DELETE ve OPTIONS metotlarının ne işe yaradığını, bir HTTP isteğinin nasıl kurulduğunu ve sunucunun nasıl cevap verdiğini gerçek örneklerle açıklayacağız. Eğer web altyapısını gerçekten anlamak istiyorsanız, bu rehber size sağlam bir temel kazandıracaktır.

HTTP Nedir ve Tarayıcı ile Sunucu Arasında Nasıl Çalışır?

HTTP, HyperText Transfer Protocol ifadesinin kısaltmasıdır ve istemci ile sunucu arasında veri alışverişi yapmak için kullanılan uygulama katmanı protokolüdür. Buradaki istemci çoğu zaman tarayıcıdır, ancak mobil uygulama, masaüstü yazılımı veya bir backend servis de istemci olabilir. Sunucu ise isteği alır, işler ve uygun bir yanıt döner.

Temel model oldukça nettir: istemci bir request gönderir, sunucu ise bir response döner. Tarayıcı bir URL açtığınızda, önce ilgili adrese bir HTTP isteği yapar. Sunucu da buna karşılık HTML, JSON, görsel, yönlendirme bilgisi veya hata mesajı gibi bir çıktı üretir.

HTTP doğası gereği stateless, yani durumsuz bir protokoldür. Bu, sunucunun her isteği bağımsız olarak değerlendirdiği anlamına gelir. Bir önceki istekte ne olduğunun otomatik olarak hatırlanmaması, cookie, session ve token gibi ek mekanizmaların neden gerekli olduğunu da açıklar.

Bugün en sık HTTP/1.1, HTTP/2 ve giderek daha fazla HTTP/3 sürümlerini görürüz. Ancak sürüm ne olursa olsun temel mantık değişmez: request gider, response gelir. Öğrenmeniz gereken çekirdek yapı budur ve geri kalan tüm detaylar bu modelin etrafında gelişir.

HTTP Request ve Response Yapısı

Bir HTTP request, istemcinin sunucuya ne istediğini bildiren standart biçimli bir mesajdır. Bu mesaj genellikle request line, headers ve opsiyonel body alanlarından oluşur. Request line içinde kullanılan metot, hedef yol ve HTTP sürümü yer alır.

Örneğin bir sayfa isteği şu şekilde görünebilir:

HTTPCopy
GET /blog/http-nedir HTTP/1.1
Host: ornek.com
User-Agent: Mozilla/5.0
Accept: text/html

Bu örnekte tarayıcı, ornek.com alan adındaki /blog/http-nedir yolunu GET metodu ile istemektedir. Host header'ı hangi domainin hedeflendiğini söylerken, User-Agent istemcinin kimliğini belirtir. Accept ise istemcinin hangi tür içerikleri kabul ettiğini gösterir.

Sunucunun döndüğü response da benzer şekilde yapılandırılmıştır. Bir status line, headers ve çoğu zaman bir body içerir. Body içinde HTML, JSON, düz metin veya başka bir veri formatı bulunabilir.

Örnek bir response şu şekilde olabilir:

HTTPCopy
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1256
Cache-Control: no-cache

<html>
  <head><title>HTTP Nedir?</title></head>
  <body><h1>HTTP Nedir?</h1></body>
</html>

Burada 200 OK, isteğin başarıyla işlendiğini belirtir. Content-Type, dönen verinin HTML olduğunu söyler. Body kısmında ise doğrudan tarayıcının render edeceği içerik yer alır.

Request İçindeki Temel Parçalar: URL, Method, Headers, Body

Bir HTTP isteğini anlamanın en iyi yolu onu parçalara ayırmaktır. Request'in en kritik bölümleri URL, method, headers ve body'dir. Her biri sunucunun isteği doğru yorumlaması için farklı bir rol üstlenir.

URL, hangi kaynağa erişmek istediğinizi belirtir. Örneğin https://api.ornek.com/users/42 adresinde protokol https, host api.ornek.com, path /users/42 kısmıdır. Gerekirse query string ile ek filtreler veya parametreler de URL içinde taşınabilir.

Method, bu kaynak üzerinde ne yapmak istediğinizi söyler. Aynı URL'ye GET ile erişmek başka, DELETE ile erişmek bambaşka bir anlam taşır. Bu nedenle URL kaynak kimliğini, method ise eylemi ifade eder.

Headers, request hakkında meta bilgi taşır. Örneğin kimlik doğrulama bilgisi, içerik tipi, kabul edilen veri formatı, dil tercihleri veya cookie bilgileri header içinde iletilebilir. Header'lar, istemci ile sunucu arasında kuralların netleşmesini sağlar.

Body ise genellikle sunucuya veri göndermek istediğiniz durumlarda kullanılır. Özellikle POST, PUT ve PATCH isteklerinde JSON, form verisi veya dosya yükleme gibi veriler body içinde taşınır. GET isteklerinde body kullanımı teorik olarak mümkün olsa da pratikte yaygın ve önerilen bir yaklaşım değildir.

Aşağıdaki tablo, request bileşenlerini hızlıca özetler:

Bileşen	Ne İşe Yarar?	Örnek
URL	Hangi kaynağa erişileceğini belirtir	/products/15
Method	Kaynak üzerinde hangi işlem yapılacağını belirtir	GET, POST
Headers	Meta bilgi taşır	Content-Type: application/json
Body	Sunucuya gönderilen veri	{ "name": "Ali" }

GET, POST, PUT, PATCH, DELETE ve OPTIONS Metotları

HTTP metotları, istemcinin kaynak üzerinde yapmak istediği işlemi ifade eder. Aynı endpoint farklı metotlarla farklı davranabilir. Bu nedenle sadece URL'yi bilmek yetmez, hangi method ile çağrı yapıldığını da bilmek gerekir.

En sık kullanılan metot GET'tir. GET, veri okumak için kullanılır ve ideal olarak sunucudaki durumu değiştirmez. Örneğin bir ürün listesini çekmek için yapılan istek şöyledir:

HTTPCopy
GET /api/products?page=1&limit=10 HTTP/1.1
Host: api.ornek.com
Accept: application/json

Bu isteğe karşılık sunucu şu yanıtı dönebilir:

HTTPCopy
HTTP/1.1 200 OK
Content-Type: application/json

[
  { "id": 1, "name": "Laptop" },
  { "id": 2, "name": "Klavye" }
]

POST, yeni veri oluşturmak veya sunucuda işlem başlatmak için kullanılır. Örneğin yeni bir kullanıcı kaydı oluşturmak için şu istek gönderilebilir:

HTTPCopy
POST /api/users HTTP/1.1
Host: api.ornek.com
Content-Type: application/json
Accept: application/json

{
  "name": "Ayşe Yılmaz",
  "email": "ayse@example.com"
}

Başarılı bir response şöyle olabilir:

HTTPCopy
HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/101

{
  "id": 101,
  "name": "Ayşe Yılmaz",
  "email": "ayse@example.com"
}

PUT, bir kaynağın tamamını güncellemek için kullanılır. Yani istemci çoğu zaman kaynağın yeni halini bütünüyle gönderir. Örnek:

HTTPCopy
PUT /api/users/101 HTTP/1.1
Host: api.ornek.com
Content-Type: application/json

{
  "name": "Ayşe Yılmaz",
  "email": "ayse.yilmaz@example.com",
  "status": "active"
}

PATCH ise kaynağın sadece belirli alanlarını güncellemek için kullanılır. Tüm nesneyi göndermek zorunda kalmadan kısmi güncelleme yapılmasını sağlar:

HTTPCopy
PATCH /api/users/101 HTTP/1.1
Host: api.ornek.com
Content-Type: application/json

{
  "status": "inactive"
}

DELETE, bir kaynağı silmek için kullanılır. Örneğin bir kullanıcıyı kaldırmak için:

HTTPCopy
DELETE /api/users/101 HTTP/1.1
Host: api.ornek.com
Accept: application/json

Buna karşılık aşağıdaki gibi bir response alınabilir:

HTTPCopy
HTTP/1.1 204 No Content

OPTIONS ise bir kaynak için hangi metotların veya iletişim seçeneklerinin desteklendiğini öğrenmek için kullanılır. Özellikle CORS süreçlerinde tarayıcılar bunu sıkça kullanır:

HTTPCopy
OPTIONS /api/users HTTP/1.1
Host: api.ornek.com
Origin: https://app.ornek.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, Authorization

Sunucu şu cevabı dönebilir:

HTTPCopy
HTTP/1.1 204 No Content
Allow: GET, POST, OPTIONS
Access-Control-Allow-Origin: https://app.ornek.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

Headers Nedir? En Sık Kullanılan HTTP Header Türleri

Header'lar, request ve response mesajlarının görünmeyen ama çok kritik parçalarıdır. Sunucuya ya da istemciye içerik tipi, yetkilendirme, önbellekleme, dil tercihi, bağlantı yönetimi ve güvenlik gibi konularda bilgi verirler. Birçok durumda sistemin doğru çalışması doğrudan header'ların doğru kurgulanmasına bağlıdır.

İsteklerde en sık görülen header'lardan biri Authorization'dır. API'lerde token ile kimlik doğrulama yapmak için yaygın şekilde kullanılır. Content-Type, body içindeki verinin hangi formatta olduğunu belirtirken, Accept istemcinin hangi yanıt türlerini beklediğini söyler.

Örnek bir API isteği şu şekilde olabilir:

HTTPCopy
POST /api/orders HTTP/1.1
Host: api.ornek.com
Authorization: Bearer abc123token
Content-Type: application/json
Accept: application/json

Response tarafında ise Content-Type, Set-Cookie, Cache-Control, Location ve Access-Control-Allow-Origin gibi header'lar öne çıkar. Bu header'lar tarayıcının içeriği nasıl işleyeceğini veya sonraki davranışını etkileyebilir. Özellikle güvenlik ve performans optimizasyonlarında response header'ları büyük önem taşır.

Aşağıda sık kullanılan bazı header'ları görebilirsiniz:

Header	Kullanım Amacı	Örnek
Host	Hedef domain bilgisini belirtir	Host: api.ornek.com
Content-Type	Gönderilen veya dönen veri türünü belirtir	application/json
Accept	İstemcinin kabul ettiği içerik türlerini söyler	Accept: application/json
Authorization	Kimlik doğrulama bilgisi taşır	Bearer token
Cookie	Tarayıcıdaki cookie verilerini sunucuya gönderir	Cookie: sessionId=xyz
Set-Cookie	Sunucunun tarayıcıya cookie yazmasını sağlar	Set-Cookie: theme=dark
Location	Yönlendirme veya oluşturulan kaynak adresi verir	Location: /login
Cache-Control	Önbellek davranışını belirler	no-cache, max-age=3600

Body Nedir? JSON, Form Verisi ve Veri Gönderme Mantığı

HTTP body, istemcinin sunucuya veri gönderdiği veya sunucunun istemciye veri döndürdüğü ana içerik alanıdır. Özellikle API iletişiminde body çoğu zaman JSON formatında kullanılır. Bunun yanında form verisi, çok parçalı dosya yüklemeleri ve düz metin gibi farklı formatlar da mümkündür.

Modern uygulamalarda en yaygın senaryo JSON body göndermektir. Bunun için request içinde Content-Type: application/json header'ı yer alır ve gövde kısmında JSON nesnesi bulunur. Sunucu bu veriyi parse ederek işlem yapar.

Örnek bir giriş isteği:

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

{
  "email": "kullanici@example.com",
  "password": "gizli123"
}

Bazen klasik HTML formlarında application/x-www-form-urlencoded kullanılır. Bu durumda veri anahtar-değer biçiminde gönderilir. Dosya yüklemelerinde ise multipart/form-data tercih edilir ve body sınırlandırılmış parçalardan oluşur.

Örneğin form verisi şu şekilde olabilir:

HTTPCopy
POST /iletisim HTTP/1.1
Host: ornek.com
Content-Type: application/x-www-form-urlencoded

name=Ali+Kaya&email=ali%40example.com&message=Merhaba

Body kullanımında önemli nokta, veri formatı ile Content-Type bilgisinin uyumlu olmasıdır. Sunucu JSON beklerken form verisi gönderilirse hata alınabilir. Bu yüzden request body tasarımı, backend ve frontend tarafının ortak protokolü gibi düşünülmelidir.

Cookies Nedir ve HTTP İçinde Nasıl Taşınır?

HTTP stateless olduğu için, kullanıcının oturum durumunu veya tercihlerini birden fazla istek arasında korumak için ek mekanizmalara ihtiyaç vardır. Cookie, bu amaçla kullanılan en temel araçlardan biridir. Sunucu tarayıcıya bir cookie gönderir, tarayıcı da sonraki isteklerde bunu tekrar sunucuya iletir.

Sunucu cookie yazmak istediğinde response içinde Set-Cookie header'ı kullanır. Tarayıcı bu değeri saklar ve ilgili domain ile yol koşullarına uygunsa sonraki isteklerde Cookie header'ı ile geri yollar. Böylece oturum takibi, dil seçimi, tema tercihi veya bazı güvenlik akışları mümkün hale gelir.

Cookie set eden bir response örneği:

HTTPCopy
HTTP/1.1 200 OK
Content-Type: application/json
Set-Cookie: sessionId=abc789; Path=/; HttpOnly; Secure; SameSite=Lax

{
  "message": "Giriş başarılı"
}

Sonraki request'te tarayıcı bu cookie'yi otomatik olarak ekleyebilir:

HTTPCopy
GET /api/profile HTTP/1.1
Host: api.ornek.com
Cookie: sessionId=abc789
Accept: application/json

Cookie öznitelikleri güvenlik açısından çok önemlidir. HttpOnly, JavaScript üzerinden cookie erişimini engelleyerek XSS riskini azaltır. Secure, cookie'nin yalnızca HTTPS üzerinden taşınmasını sağlar. SameSite ise özellikle CSRF risklerini azaltmak için cross-site davranışını sınırlar.

2xx, 3xx, 4xx ve 5xx Durum Kodları Ne Anlatır?

HTTP response içindeki durum kodu, isteğin sonucunu hızlıca anlamanın en temel yoludur. Kodlar yüzlerce olası durumu temsil etse de, pratikte bunlar sınıflar halinde düşünülür. İlk rakam, response'un genel kategorisini belirler.

2xx kodları başarıyı ifade eder. 200 en yaygın olanıdır ve isteğin başarılı şekilde işlendiğini söyler. 201 Created, yeni bir kaynak oluşturulduğunda kullanılır. 204 No Content ise işlem başarılı olsa da geri dönecek body olmadığını belirtir.

Örnekler:

HTTPCopy
HTTP/1.1 200 OK
Content-Type: application/json

{ "id": 1, "name": "Ürün" }

HTTPCopy
HTTP/1.1 201 Created
Location: /api/products/55
Content-Type: application/json

{ "id": 55, "name": "Yeni Ürün" }

HTTPCopy
HTTP/1.1 204 No Content

3xx kodları yönlendirme sınıfıdır. Tarayıcıya ya da istemciye, istenen kaynağın başka bir adreste olduğunu söyler. 301 kalıcı yönlendirme, 302 geçici yönlendirme, 304 ise önbellek doğrulama bağlamında içeriğin değişmediğini belirtir.

HTTPCopy
HTTP/1.1 301 Moved Permanently
Location: https://www.ornek.com/yeni-sayfa

HTTPCopy
HTTP/1.1 304 Not Modified

4xx kodları istemci taraflı hataları gösterir. Yani request'te eksik, hatalı veya yetkisiz bir durum vardır. 400 Bad Request bozuk istek anlamına gelirken, 401 Unauthorized kimlik doğrulama gerektiğini, 403 Forbidden erişim izni olmadığını, 404 Not Found ise kaynağın bulunamadığını ifade eder.

HTTPCopy
HTTP/1.1 400 Bad Request
Content-Type: application/json

{ "error": "Geçersiz JSON formatı" }

HTTPCopy
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer
Content-Type: application/json

{ "error": "Token gerekli" }

HTTPCopy
HTTP/1.1 404 Not Found
Content-Type: application/json

{ "error": "Kullanıcı bulunamadı" }

5xx kodları ise sunucu taraflı hataları temsil eder. İstemci doğru istek göndermiş olabilir, ancak sunucu isteği işlerken sorun yaşamıştır. 500 Internal Server Error genel sunucu hatasıdır. 502 Bad Gateway, 503 Service Unavailable ve 504 Gateway Timeout gibi kodlar ise çoğunlukla dağıtık sistemlerde, proxy veya gateway katmanlarında görülür.

HTTPCopy
HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{ "error": "Beklenmeyen sunucu hatası" }

Durum kodlarını sadece ezberlemek yerine mantığını kavramak daha değerlidir. 2xx başarılı, 3xx yönlendirme, 4xx istemci sorunu, 5xx sunucu sorunu şeklinde düşündüğünüzde hata ayıklama çok daha kolay hale gelir.

Gerçek Hayatta Bir Sayfa Açılırken HTTP Akışı Nasıl İlerler?

Bir kullanıcı tarayıcıya bir URL yazdığında aslında arka planda tek bir istek değil, bir dizi HTTP etkileşimi gerçekleşir. İlk aşamada tarayıcı hedef adrese bir GET isteği gönderir ve sunucudan HTML içeriği ister. Sunucu 200 OK ile HTML dönerse tarayıcı bu belgeyi ayrıştırmaya başlar.

Ancak HTML içinde CSS, JavaScript, font ve görsel dosyaları varsa süreç burada bitmez. Tarayıcı bu kaynakların her biri için ek HTTP istekleri üretir. Yani tek bir sayfanın açılışı sırasında onlarca hatta yüzlerce request oluşabilir.

Örnek bir ilk istek şu şekilde olabilir:

HTTPCopy
GET / HTTP/1.1
Host: www.ornek.com
Accept: text/html

Sunucu HTML döndürdükten sonra tarayıcı aşağıdaki gibi ek istekler yapabilir:

HTTPCopy
GET /assets/app.css HTTP/1.1
Host: www.ornek.com

HTTPCopy
GET /assets/app.js HTTP/1.1
Host: www.ornek.com

HTTPCopy
GET /images/logo.png HTTP/1.1
Host: www.ornek.com

Eğer sayfa açıldıktan sonra JavaScript bir API çağrısı yaparsa bu da yeni bir HTTP isteği oluşturur. Örneğin kullanıcı panelindeki veriler sonradan yüklenebilir:

HTTPCopy
GET /api/dashboard HTTP/1.1
Host: api.ornek.com
Authorization: Bearer xyz-token
Accept: application/json

Bu akış, web sitelerinin sadece görsel katmandan ibaret olmadığını gösterir. Özellikle Pratikweb gibi hazır web sitesi ve geliştirilebilir platform çözümleri sunan yapılarda, görünürde sade olan bir arayüzün arkasında çok sayıda HTTP etkileşimi bulunur. Sayfa içeriği, yönetim paneli, kullanıcı işlemleri ve servis bazlı yapıların tümü bu request-response mantığı üzerinde yükselir.

HTTP Öğrenirken Dikkat Edilmesi Gereken Pratik Noktalar

HTTP'yi öğrenirken en sık yapılan hata, sadece metot isimlerini ezberleyip iletişim modelini gözden kaçırmaktır. Oysa asıl önemli olan, istemcinin ne gönderdiğini ve sunucunun ne döndürdüğünü okuyabilmektir. Tarayıcı geliştirici araçları, cURL komutları ve API istemcileri bu yüzden çok değerlidir.

Özellikle Network sekmesi, gerçek request ve response mesajlarını incelemek için en iyi araçlardan biridir. Burada method, URL, status code, request headers, response headers, body ve süre bilgilerini görebilirsiniz. Öğrendiğiniz kavramları canlı trafik üzerinde gözlemlemek teorik bilgiyi çok daha kalıcı hale getirir.

HTTP çalışırken şu noktalara dikkat etmek faydalıdır:

• Method doğru seçilmiş mi?
• URL gerçekten doğru kaynağı mı işaret ediyor?
• Header'lar beklenen formatta mı?
• Body ile Content-Type uyumlu mu?
• Durum kodu ne söylüyor?
• Gerekliyse cookie veya authorization bilgisi taşınıyor mu?

Bir API sorunu yaşadığınızda önce status code'a, sonra response body'ye, ardından request header ve body yapısına bakmak genellikle en hızlı teşhis yöntemidir. 404 görüyorsanız yol yanlış olabilir, 401 alıyorsanız token eksik olabilir, 415 alıyorsanız içerik tipi desteklenmiyor olabilir. Yani HTTP, sadece veri taşımakla kalmaz, aynı zamanda hata ayıklama için çok açık ipuçları da sağlar.

Sonuç: HTTP'yi Anlamak Web Altyapısını Anlamanın Anahtarıdır

HTTP'yi gerçekten anlamak, web dünyasında olup biteni ezberden değil mantık üzerinden okuyabilmenizi sağlar. Bir sayfa neden açılmıyor, bir API neden hata veriyor, bir form neden veri göndermiyor ya da bir oturum neden düşüyor gibi soruların çoğu request ve response düzeyinde cevaplanır. Bu yüzden HTTP bilgisi, yalnızca backend geliştiriciler için değil, frontend geliştiriciler, teknik içerik yöneticileri ve dijital ürün ekipleri için de temel bir yetkinliktir.

Bundan sonraki adımınız, gördüğünüz her web işlemine HTTP gözlüğüyle bakmak olmalı. Tarayıcı geliştirici araçlarında istekleri inceleyin, örnek API çağrıları yapın ve status code ile header'ları bilinçli şekilde yorumlamaya başlayın. Web altyapısını öğrenme yolculuğunda en güçlü başlangıç noktalarından biri tam olarak budur.