Mehmet

WFN Üye
Konular
1,851
Mesajlar
1,852
Çözüm
0
Ticaret Puanı
0
Üyelik
1 Ay 6 Gün
Konum
YurtDışı
Web Sitesi
Var
Alanı
Google Adsense
1/1
Konu sahibi

HTTP isteği nedir?​


HTTP isteği, bir istemcinin web sunucusundan kaynak istemek veya sunucuya veri göndermek için oluşturduğu iletişim mesajıdır. Tarayıcıda bir sayfayı açtığınızda, form gönderdiğinizde ya da bir web uygulaması API çağrısı yaptığında HTTP isteği gönderilir. Sunucu bu isteği değerlendirir ve HTTP yanıtı döndürür.

HTTP isteği nasıl çalışır?​


Bir istemci; tarayıcı, mobil uygulama, JavaScript kodu veya başka bir sunucu olabilir. İstemci, hangi işlemi istediğini HTTP yöntemiyle belirtir ve isteği sunucunun ilgili adresine gönderir. Sunucu isteği doğrular, gerekli işlemi yapar ve sonucu durum kodu, başlıklar ve gerekirse gövde içeren bir yanıtla bildirir.

Bir isteğin temel parçaları şunlardır:

  • Yöntem: Yapılacak işlemi belirtir. GET veri okumak, POST yeni veri göndermek, PUT veya PATCH veri güncellemek, DELETE veri silmek için kullanılır.
  • Yol: Sunucuda hangi kaynağa erişileceğini gösterir. Örneğin /urunler/42, 42 kimlikli ürünü temsil edebilir.
  • Başlıklar: İsteğin biçimi, istemci bilgisi veya kimlik doğrulama gibi ek bilgileri taşır. Content-Type ve Authorization yaygın örneklerdir.
  • Gövde: Özellikle POST, PUT ve PATCH isteklerinde sunucuya gönderilen veridir. JSON, form verisi veya dosya içerebilir.

Kurgu ürün örneğinde HTTP/1.1 isteğinin okunabilir başlık bölümü şöyle gösterilebilir. HTTP/2 ve HTTP/3 tel üzerindeki aynı metinsel satır biçimini kullanmaz:

Kod:
GET /urunler/42 HTTP/1.1
Host: example.com
Accept: application/json

Burada istemci, /urunler/42 yolundaki veriyi istediğini ve yanıtı JSON biçiminde beklediğini bildirir. Sunucu isteği başarıyla işlerse yanıt gövdesinde ürün verisi bulunabilir. Kaynak bulunamazsa farklı bir durum kodu, sunucu tarafında hata oluşursa başka bir hata kodu döner.

HTTP yöntemini ve veriyi seçme​


İşleme başlamadan önce isteğin amacını belirlemek, yanlış yöntem ve veri biçimi kullanımını önler. Aşağıdaki ayrım pratik bir başlangıç noktasıdır:

AmaçYöntemGövdeTipik sonuç
Veri görüntülemekGETGenellikle yokKaynak okunur
Yeni kayıt oluşturmakPOSTGenellikle varYeni kaynak oluşturulur
Mevcut kaydı değiştirmekPUT veya PATCHGenellikle varKaynak güncellenir
Kaydı kaldırmakDELETEÇoğunlukla yokKaynak silinir veya silinmek üzere işaretlenir

Örneğin bir kayıt oluştururken gövde JSON ise başlıklarda Content-Type: application/json belirtilmelidir. Sunucu ayrıca zorunlu alanları, veri türlerini ve kullanıcının işlem yetkisini kontrol etmelidir. GET sunucuda istenen veri değişikliğini başlatan bir yöntem olarak tasarlanmamalıdır. Buna karşılık karmaşık arama gibi bazı okuma işlemleri API sözleşmesinde POST ile tanımlanabilir; istemci kendi varsayımı yerine sözleşmeyi izlemelidir.

Bir isteği incelerken izlenecek adımlar​


  1. Amacı belirleyin: Veriyi mi okuyacağınızı, yeni kayıt mı oluşturacağınızı, güncelleme mi yapacağınızı yoksa silme mi isteyeceğinizi netleştirin.
  2. Yöntem ve yolu seçin: Kaynağın doğru yolunu ve amaca uygun HTTP yöntemini kullanın. Yol ile yöntemin birlikte hangi işlemi ifade ettiğini API belgelerinden kontrol edin.
  3. Gerekli başlıkları ekleyin: JSON gönderiyorsanız içerik türünü, kimlik doğrulama gerekiyorsa uygulamanın beklediği yetkilendirme bilgisini ekleyin.
  4. Gövdeyi doğrulayın: Gönderilen JSON veya form verisinde zorunlu alanların bulunduğunu ve değerlerin beklenen biçimde olduğunu kontrol edin.
  5. Yanıtı okuyun: Önce HTTP durum koduna, sonra yanıt başlıklarına ve gövdesine bakın. Başarılı görünen bir bağlantı, uygulama işleminin de başarılı olduğu anlamına gelmeyebilir; yanıt gövdesindeki hata alanlarını da değerlendirin.

Başarı yanıtları genellikle 2xx grubundadır. 4xx grubundaki sonuçlar çoğunlukla hatalı istek, eksik kimlik doğrulama veya yetki sorunu olduğunu; 5xx grubundaki sonuçlar ise sunucunun isteği işlerken sorun yaşadığını gösterir. Kesin anlam, kullanılan API'nin belgelerine ve yanıt gövdesine göre belirlenmelidir.

Sık yapılan hatalar​


En yaygın hata, isteğin yöntemi ile amacının uyuşmamasıdır. İkinci önemli hata, JSON gönderildiği halde Content-Type başlığının belirtilmemesi veya gövdenin geçersiz JSON olmasıdır. Ayrıca 401 ile 403 aynı değildir: ilki çoğunlukla geçerli kimlik doğrulama bilgisinin bulunmadığını, ikincisi sunucunun isteği anlayıp yerine getirmeyi reddettiğini ifade eder. 403, istemcinin kimliğinin mutlaka bilindiğini veya doğrulandığını kanıtlamaz.

Tarayıcı geliştirici araçlarında Network sekmesini açarak bir isteğin yöntemini, yolunu, başlıklarını, gönderilen gövdeyi, durum kodunu ve yanıtını birlikte inceleyebilirsiniz. Böylece sorun sunucuya ulaşmadan önce mi, doğrulama aşamasında mı, yoksa sunucu işlemi sırasında mı oluşuyor ayırt edebilirsiniz.

Sık sorulan sorular​


Accept ile Content-Type başlıkları aynı şeyi mi söyler?​


Hayır. Accept, istemcinin kabul edebileceği yanıt biçimlerini bildirir; Content-Type ise gönderilen mesaj içeriğinin türünü tanımlar. JSON yanıt istemek, gönderdiğiniz gövdenin de otomatik JSON olduğu anlamına gelmez.

HTTPS kullanınca HTTP isteğinin yapısı değişir mi?​


Yöntem, hedef, başlık ve içerik kavramları devam eder; HTTP mesajları TLS koruması içinde taşınır. Bu, yanlış parametreyi veya yetkisiz işlemi kendiliğinden düzeltmez. HTTPS adresinde de doğru uygulama sözleşmesi gerekir.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Konuyu görüntüleyenler

Bu konuyu şu anda görüntüleyen üye bulunmuyor.