HTTP İstek Yöntemleri Nelerdir ve Ne İşe Yarar?
HTTP istek yöntemi, istemcinin hedef kaynağa yönelik niyetini sunucuya bildiren standart bir istek bileşenidir. Yöntem, hedef kaynak üzerinde ne tür bir işlem beklendiğini tanımlar; isteğin nasıl taşındığı bu anlamı belirlemez.
Bir kaynağın HTML sayfası veya yapılandırılmış veri içeren JSON belgesi gibi istemciye aktarılabilen biçimine temsil denir. URI ise hedef kaynağı tanımlayan kimliktir; HTTP isteklerinde kaynak adresi olarak kullanılır.
Aynı kaynak adresine farklı yöntemlerle gönderilen istekler, sunucudan farklı işlemler ister. GET bir temsilin alınmasını isterken PUT hedef URI'de kaynak oluşturmayı veya mevcut durumu gönderilen temsil ile değiştirmeyi, DELETE ise hedef URI ile kaynağın sunucudaki mevcut işlevi arasındaki bağlantının kaldırılmasını ister.
GET, HEAD, POST, PUT, PATCH, DELETE ve OPTIONS yöntemlerini doğru karşılaştırmak için dört temel özellik belirleyicidir: güvenli olup olmadıkları, idempotent olup olmadıkları, istek gövdesinin standart bir anlam taşıyıp taşımadığı ve hedef kaynak üzerinde hangi işlemi ifade ettikleri. HTTP bağlamındaki güvenli sözcüğü şifreleme veya saldırılara karşı koruma anlamına gelmez; istemcinin o yöntemle kaynak üzerinde değişiklik istememesiyle ilgilidir.
Güvenli Olma ve İdempotentlik Farklı Özelliklerdir
Bir yöntemin güvenli olması, istemcinin o yöntemle sunucuda durum değişikliği istemediğini ve böyle bir değişiklik beklemediğini ifade eder. İdempotent bir yöntemde aynı isteğin birden fazla kez uygulanması, sunucuda istenen etkiyi tek kez uygulanmasına göre değiştirmez.
Güvenli Yöntemlerde Amaç Kaynak Durumunu Değiştirmemektir
GET, HEAD ve OPTIONS bu kapsamdaki güvenli yöntemlerdir. Sunucu erişim kaydı tutabilir, sayaç güncelleyebilir veya başka iç işlemler yapabilir; bunlar yöntemin güvenli niteliğini tek başına bozmaz, çünkü istemcinin tanımlı isteği kaynak durumunu değiştirmek değildir.
Bu nedenle güvenli sözcüğünü “zararsız”, “kimlik doğrulama gerektirmez” veya “bağlantıyı şifreleyen TLS kullanılmasa da sorun olmaz” şeklinde yorumlamak yanlıştır. Güvenli olma, HTTP yönteminin tanımlı anlamıyla ilgilidir; erişim kontrolü ve bağlantının korunması ayrı konulardır.
Sunucu, kayıt silme gibi durum değiştiren bir işlemi GET isteğiyle gerçekleştirmemelidir. Tarayıcılar veya otomatik tarama yazılımları bu adresi önceden istediğinde silme işlemi yanlışlıkla tetiklenebilir. Yöntem adı, isteği gönderenin yetkili olduğunu da kanıtlamaz; sunucu erişim kurallarını her istekte uygulamalıdır.
İdempotent Yöntemde Aynı Yanıt Değil, Amaçlanan Etki Esastır
GET, HEAD, PUT, DELETE ve OPTIONS idempotenttir. Örneğin aynı PUT isteğinin yeniden gönderilmesi, arada başka bir değişiklik olmadığı varsayımıyla hedef kaynağı yine aynı istenen duruma getirir. Aynı DELETE isteğinin ilkinde kaynak kaldırılıp sonraki istekte farklı bir durum kodu dönmesi mümkündür; buna rağmen hedef üzerindeki amaçlanan silme etkisi değişmediği için yöntem idempotent kalır.
POST ve PATCH ise yöntem tanımları gereği idempotent değildir. Belirli bir uygulamada POST veya PATCH işlemi, tekrarlandığında aynı etkiyi verecek şekilde tasarlanabilir, ancak istemci yalnız yöntem adına bakarak bu davranışı varsaymamalıdır.
GET, HEAD, POST, PUT, PATCH, DELETE ve OPTIONS Karşılaştırması
Aşağıdaki tablo yöntemleri aynı dört özellik üzerinden karşılaştırır. “İstek gövdesi” sütunu, protokolün mesajda teknik olarak içerik taşıyabilmesinden çok, ilgili yöntemin standart tanımında o içeriğe genel bir anlam verilip verilmediğini gösterir.
| Yöntem | Temel amaç | Güvenli mi? | İdempotent mi? | İstek gövdesi |
|---|---|---|---|---|
| GET | Hedef kaynağın güncel temsilini almak | Evet | Evet | Genel bir anlamı yok; normalde gönderilmez |
| HEAD | GET ile aynı seçimi yapmak, yanıt içeriğini almamak | Evet | Evet | Genel bir anlamı yok; normalde gönderilmez |
| POST | İstek gövdesini hedef kaynağın kurallarına göre işlemek | Hayır | Hayır | Temel işlevin parçasıdır |
| PUT | Hedef kaynağı oluşturmak veya mevcut durumunu değiştirmek | Hayır | Evet | İstenen kaynak durumunu tanımlar |
| PATCH | Hedef kaynağa tanımlı değişiklikler uygulamak | Hayır | Hayır | Değişiklik talimatlarını taşır |
| DELETE | Hedef URI ile kaynağın sunucudaki mevcut işlevi arasındaki bağlantıyı kaldırmak | Hayır | Evet | Genel bir anlamı yok; normalde gönderilmez |
| OPTIONS | Hedefle iletişim seçeneklerini öğrenmek | Evet | Evet | Gönderilebilir ancak standart bir kullanım tanımlanmaz |
Her Yöntemin Kaynak Üzerindeki İşlemi
Uygulamaların birbirinden veri veya işlem isteyebildiği API tasarımlarında yöntem adları okuma, oluşturma, güncelleme ve silmeyle eşleştirilse de HTTP tanımları daha özeldir. Özellikle POST, PUT, PATCH ve DELETE arasındaki farkı yalnız “veri gönderiyor” veya “veri değiştiriyor” diye açıklamak yeterli değildir.
GET ve HEAD Kaynağı Okuma Niyeti Taşır
GET, hedef kaynağın seçilmiş güncel temsilinin aktarılmasını ister. Bir web sayfası, JSON temsili veya başka bir kaynak görünümü GET ile alınabilir; yöntem hedef kaynağın durumunu değiştirme isteği taşımaz.
HEAD, seçim mantığı açısından GET ile aynıdır fakat sunucu yanıt içeriğini göndermez. Bu sayede istemci, temsil verisini indirmeden yanıt başlıklarından elde edilebilen bilgileri kontrol edebilir. Sunucu, yalnız içerik üretilirken hesaplanabilen bazı başlıkları HEAD yanıtında vermeyebilir; bu nedenle HEAD yanıtı her başlık bakımından GET ile birebir aynı olmak zorunda değildir.
POST Hedef Kaynağa İşleme Talebi Gönderir
POST gövdesi, hedef kaynağın kendi kurallarına göre işlenecek veriyi taşır. Bu işlem form verisini işlemek, mevcut bir kaynağa veri eklemek, bir eylem başlatmak veya yeni bir kaynak oluşturmak gibi farklı sonuçlar doğurabilir.
POST’un anlamı “her zaman yeni kayıt oluştur” değildir. Hangi sonucun ortaya çıkacağını hedef kaynağın tanımladığı işlem belirler; POST'un bu geniş kullanım alanı nedeniyle aynı POST isteğinin yinelenmesi bazı uygulamalarda aynı işlemi ikinci kez gerçekleştirebilir.
PUT ile PATCH Gövdeleri Arasındaki Farklar
PUT, istemcinin belirlediği hedef URI'de kaynak oluşturmayı veya mevcut kaynağın durumunu istek gövdesindeki temsille değiştirmeyi ister. İstemci aynı hedefe aynı durumu tekrar gönderdiğinde amaçlanan etki değişmediği için PUT idempotenttir.
PATCH ise gönderilen içeriği hedef kaynağın yeni tam durumu olarak yorumlamaz. Gövde, kaynak üzerinde uygulanacak değişiklikleri tanımlar; bu nedenle bir alanı değiştirmek veya mevcut temsilin belirli bölümlerini güncellemek için kullanılabilir. Hedefte kaynak yoksa sunucu, yama biçimi ve izinler elverdiğinde yeni kaynak da oluşturabilir.
PATCH genel olarak idempotent değildir çünkü aynı değişiklik talimatının iki kez uygulanması, kullanılan yama biçimine ve işlem türüne göre ilk uygulamadan farklı sonuç doğurabilir. Bununla birlikte bir uygulama PATCH işlemini idempotent olacak şekilde tasarlayabilir. İstemci ayrıca, sunucunun kaynak sürümü için verdiği güçlü ETag değerini If-Match başlığında göndererek kaynağın arada değişmemiş olmasını şart koşabilir. Değer artık eşleşmiyorsa sunucu yeni değişiklik uygulamaz; istek normalde 412 Precondition Failed yanıtıyla reddedilir.
Sunucu bir PATCH belgesindeki değişikliklerin tamamını birlikte uygulamalıdır; belgenin bir bölümü uygulanamıyorsa hiçbir değişiklik yapmamalıdır. Bazı sunucular, değiştirilecek bayt aralığını bildiren Content-Range başlığıyla kısmi PUT da destekler. Ancak bu özel kullanım istemci ile sunucunun açıkça anlaşmasına bağlıdır; her sunucuda çalıştığı varsayılamaz.
DELETE Verilerin Tamamen Silindiğini Garanti Etmez
DELETE, sunucudan hedef URI ile kaynağın mevcut işlevi arasındaki bağlantıyı kaldırmasını ister. Bu işlem kaynağın ilgili URI üzerinden erişilmesini sona erdirebilir, ancak HTTP semantiği sunucunun alttaki veriyi diskten veya veritabanından kesin olarak yok etmesini zorunlu kılmaz.
DELETE idempotenttir çünkü aynı silme isteğini yeniden göndermek sunucuda farklı bir amaçlanan son durum oluşturmaz. Buna karşılık ilk ve sonraki DELETE yanıtlarının durum kodları veya yanıt içerikleri farklı olabilir.
OPTIONS Kaynağı Değiştirmeden İletişim Seçeneklerini Sorar
OPTIONS, belirli bir kaynakla hangi yollarla iletişim kurulabileceğini sorar; yıldız hedefiyle gönderildiğinde ise sorgu genel olarak sunucuya yönelir. Başarılı bir yanıt, iletişim seçeneklerini belirten alanlar içerebilir; örneğin izin verilen yöntemleri bildiren Allow alanı gönderilebilir.
OPTIONS isteği içerik taşıyabilir, ancak HTTP'nin temel tanımı bu içeriğin ne amaçla kullanılacağını belirtmez. Bu nedenle yalnız gövde taşıyabilmesi, OPTIONS yöntemini POST benzeri bir işleme yöntemine dönüştürmez.
CONNECT ve TRACE Ne İçin Kullanılır?
CONNECT, sunucudan belirtilen hedefe bir tünel açmasını ve sonraki verileri bu bağlantıdan iletmesini ister. Örneğin istemci, kendisi adına hedefe bağlantı kuran bir HTTP proxy üzerinden CONNECT kullanabilir. Tünel kurmak veriyi kendiliğinden şifrelemez; şifreleme gerekiyorsa TLS gibi ayrı bir koruma gerekir. CONNECT, güvenli veya idempotent olarak tanımlanmaz.
TRACE, isteğin karşı tarafta nasıl alındığını görmek için tanılama amacıyla kullanılır. Güvenli ve idempotent olarak tanımlanır; ancak istekte parola, oturum çerezi gibi hassas bilgiler veya gövde gönderilmez.
İstek Gövdesinin Varlığı Yöntemin Anlamını Tek Başına Belirlemez
Mesajın başlık ve gövde bölümlerinin nasıl taşınıp ayrıldığını belirleyen kurallar, yöntemin istediği işlemden ayrıdır. Bu yüzden “gövde varsa yazma işlemidir, yoksa okuma işlemidir” kuralı doğru değildir. POST, PUT ve PATCH için gövde yöntemin temel anlamının parçasıyken GET, HEAD ve DELETE gövdelerinin genel olarak tanımlanmış bir anlamı yoktur.
GET, HEAD veya DELETE gövdesi, kaynak sunucuya doğrudan yapılan ve açıkça desteklendiği bilinen özel bir kullanım yoksa gönderilmemelidir. Sunucunun destek vermesi aradaki HTTP bileşenlerinin aynı şekilde davranacağını garanti etmez; bazı uygulamalar bu istekleri reddedebilir. Tarayıcıda HTTP isteği göndermek için kullanılan Fetch API, GET ve HEAD isteklerinde gövdeye izin vermez.
Tekrarlanan İsteklerin Sunucu Üzerindeki Etkisi
İdempotentlik özellikle bağlantı kesildiğinde istemcinin isteğin uygulanıp uygulanmadığını bilemediği durumlarda önem kazanır. PUT gibi idempotent bir istek yeniden gönderildiğinde amaçlanan son durum korunabilir; yine de araya başka istemcilerin yaptığı değişiklikler veya uygulamaya özgü yan etkiler girebileceği için istemci gerçek sistem durumunu ayrıca değerlendirmelidir.
POST ve PATCH gibi yöntemlerde, işlemin tekrarlanmaya uygun olduğu veya ilk isteğin hiç uygulanmadığı bilinmiyorsa istemci otomatik yeniden deneme yapmamalıdır. Yanıt gelmemesi tek başına işlemin başarısız olduğunu göstermez; isteğin uygulanıp yalnız yanıtın kaybolmuş olması mümkündür. Ayrıca otomatik tekrarın kendisi de başarısız olursa istemci bunu otomatik olarak tekrar tekrar göndermemelidir.
