HTTP Dersleri – Ders 1 – Temel kavramlara genel bakış
HTTP Dersleri – Ders 2 – Mimari Yönleri
HTTP Dersleri – Ders 3 – İstemci Kimliği
HTTP Dersleri – Ders 4 – İstemci Doğrulama Mekanizmaları
HTTP Dersleri – Ders 5 – Güvenlik
HTTP Dersleri – Sözlük

Bu yazıda size HTTP temellerini sunacağım.

Ama neden HTTP?

Kendinize sorabileceğiniz HTTP hakkında neden okumalıyım?

Bir yazılım geliştiricisi iseniz, nasıl iletişim kurduğunu öğrenerek, daha iyi uygulamaları nasıl yazacağınızı anlayacaksınız. Sistem mimarı veya ağ yöneticisiyseniz, karmaşık ağ mimarileri tasarlama konusunda daha derin bilgi sahibi olursunuz.

Günümüzde çok önemli mimari tarz olan REST, tamamen HTTP özelliklerini kullanmaya dayanıyor; bu nedenle HTTP’yi anlamayı daha da önemli hale getiriyor. Harika RESTFULL uygulamalar yapmak istiyorsanız öncelikle HTTP’yi anlamalısınız.

Yani, World Wide Web ve ağ iletişiminin ardındaki temel kavramları anlama ve öğrenme şansını tepmek mi istiyorsun?

Umarım istemiyorsundur ?

Makalenin odak noktası, HTTP’nin en önemli bölümlerini mümkün olan en basit şekilde açıklamak üzerine olacak. Buradaki düşünce, HTTP ile ilgili tüm yararlı bilgileri tek bir yerde organize etmektir; böylece, ihtiyaç duyduğunuz bilgileri bulmak için kitaplara ve RFC’lere gitme zamanınızı kurtarabilirsiniz.

Bu makalede neler öğreneceksiniz?

• HTTP tam olarak nedir
• Kaynaklar
• Web İstemcisi ve Web Sunucusu arasındaki bilgiler nasıl aktarılır
• Mesajlar ve bazı mesaj örnekleri
• MIME türleri
• Talep Yöntemleri
• Başlıkları
• Durum kodları

Daha fazla ado olmadan, içeriye girelim.

HTTP tanımı

HTTP’nin kurucusu Tim Berners-Lee (aynı zamanda World Wide Web’in mucidi olduğu düşünülen adam). HTTP’nin geliştirilmesi için önemli olan diğer isimler arasında da REST mimari stilinin yaratıcısı Roy Fielding var.

Köprü Metni Aktarım Protokolü (Hyper-Text Transfer Protocol), uygulamaların birbirleriyle iletişim kurmak için kullandığı protokoldür. Özünde, HTTP, tüm internetteki medya dosyalarını istemciler ve sunucular arasında iletmekle görevlidir. HTML, görüntüler, metin dosyaları, filmler ve bunlar arasındaki her şeyi içerir ve bunu hızlı, güvenilir bir şekilde yapar.

HTTP, uygulama katmanındaki iletişim için kullanıldığından, uygulama protokolüdür, aktarım protokolü değildir. Burada belleğinizi tazelemek için netmork katmanlarına bakalım;

Kaynaklar

İnternetteki her şey bir kaynaktır ve HTTP kaynaklar ile çalışır. Bu dosyalar, akışlar, hizmetler ve her şeyi içerir. HTML sayfası bir kaynaktır, youtube videonuz bir kaynaktır, günlük sayfanızdaki bir web uygulamasındaki e-tablonuzu bir kaynaktır… olayı anladınız.

Fakat bir kaynaktan diğerini nasıl ayırt edersiniz?

Onlara bir URL vererek (Uniform resource locators).

URL, tarayıcınızın kaynağı bulabileceği benzersiz yere işaret eder.

Web İstemcisi ve Web Sunucusu arasındaki iletiler nasıl değişir

Her içerik parçası, her kaynak Web sunucusunda (HTTP sunucusu) bulunur. Bu sunucular, bu kaynakları sağlamak için bir HTTP isteği beklemektedir.

Ancak nasıl Web sunucusundan bir kaynak isteğinde bulunuyorsunuz?

Elbette bir HTTP istemcisine ihtiyacınız var ?

Bu makaleyi okumak için şu anda bir HTTP istemcisi kullanıyorsunuz. Web tarayıcıları HTTP istemcileridir. Kaynakları bilgisayarınıza almak için HTTP sunucularıyla iletişim kurarlar. En popüler istemcilerden bazıları Google Chrome, Mozilla Firefox, Opera, Apple’ın Safari ve ne yazık ki hala rezil Internet Explorer.

Mesajlar ve bazı mesaj örnekleri

Peki, HTTP mesajı nasıl görünüyor?

Çok fazla konuşmadan, HTTP mesajlarına bazı örnekler verelim:

GET İsteği

GET /repos/CodeMazeBlog/ConsumeRestfulApisExamples HTTP/1.1
Host: api.github.com
Content-Type: application/json
Authorization: Basic dGhhbmtzIEhhcmFsZCBSb21iYXV0LCBtdWNoIGFwcHJlY2lhdGVk
Cache-Control: no-cache

Post İsteği

POST /repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks?access_token=5643f4128a9cf974517346b2158d04c8aa7ad45f HTTP/1.1
Host: api.github.com
Content-Type: application/json
Cache-Control: no-cache
 
{
  "url": "http://www.example.com/example",
  "events": [
    "push"
  ],
  "name": "web",
  "active": true,
  "config": {
    "url": "http://www.example.com/example",
    "content_type": "json"
  }
}

İşte bir GET ve bir POST isteği örneği. Bu isteklerin farklı kısımlarını hızla gözden geçirelim.

Talebin ilk satırı, talep hattı için ayrılmıştır. İstek yöntemi adı, istek URI’si ve HTTP sürümünden oluşur.

Sonraki birkaç satır istek üstbilgilerini temsil etmektedir. İstek başlıkları, istekte bulunan içerik türleri, yanıtta beklenen içerik, yetkilendirme bilgileri vb. Gibi ek bilgi sağlar;

GET isteği için hikaye burada bitiyor. POST isteğinde ayrıca bir gövde olabilir ve gövde mesajı şeklinde ek bilgi taşıyabilirsiniz. Bu durumda, URI’de belirtilen verilen repo için GitHub web kancasının nasıl oluşturulması gerektiği konusunda ek bilgi içeren bir JSON mesajıdır. Bu mesaj, web kağıdının oluşturulması için gereklidir, bu nedenle bu bilgileri GitHub API’sine sunmak için POST isteği kullanıyoruz.

İstek hattı ve istek başlıkları, <CR> <LF> (satır başı ve satır besleme \r \n) tarafından takip edilmeli ve ileti üstbilgileri ile ileti gövdesi arasında yalnızca CRLF içeren tek bir boş satır bulunmalıdır.

HTTP isteği için referans: https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html

Ve bu isteklere cevap olarak ne alacağız?

Yanıt mesajı

HTTP/1.1 200 OK
Server: GitHub.com
Date: Sun, 18 Jun 2017 13:10:41 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Status: 200 OK
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 4996
X-RateLimit-Reset: 1497792723
Cache-Control: private, max-age=60, s-maxage=60
 
[
  {
    "type": "Repository",
    "id": 14437404,
    "name": "web",
    "active": true,
    "events": [
      "push"
    ],
    "config": {
      "content_type": "json",
      "insecure_ssl": "0",
      "url": "http://www.example.com/example"
    },
    "updated_at": "2017-06-18T12:17:15Z",
    "created_at": "2017-06-18T12:03:15Z",
    "url": "https://api.github.com/repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks/14437404",
    "test_url": "https://api.github.com/repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks/14437404/test",
    "ping_url": "https://api.github.com/repos/CodeMazeBlog/ConsumeRestfulApisExamples/hooks/14437404/pings",
    "last_response": {
      "code": 422,
      "status": "misconfigured",
      "message": "Invalid HTTP Response: 404"
    }
  },
]

Yanıt mesajı, ilk satırın yanıt durumu hakkında taşıdığı bilgi hariç, istekle hemen hemen aynı şekilde yapılandırılmıştır. ?

Durum satırı, yanıt başlıkları ve yanıt gövdesi tarafından izlenir.

HTTP yanıtı için referans: https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html

MIME türleri

MIME türleri internetteki dosya türlerini tanımlamak için standart bir yol olarak kullanılır. Tarayıcınız bir MIME türleri listesine sahiptir ve web sunucuları için de aynı şey geçerlidir. Bu şekilde, dosyalar işletim sisteminden bağımsız olarak aynı şekilde aktarılabilir.

Aslında multimedya e-postası için geliştirildikleri için MIME, Çok Amaçlı İnternet Posta Uzantısı anlamına gelir. O zamandan beri HTTP ve diğer pek çok protokol için kullanılmak üzere uyarlandılar.

Her MIME türü, bir tür, alt türü ve aşağıdaki biçimde isteğe bağlı parametrelerin bir listesinden oluşur: type / subtype; Isteğe bağlı parametreler.

İşte birkaç örnek:

Content-Type: application/json
Content-Type: text/xml; charset=utf-8
Accept: image/gif

Sık kullanılan MIME türlerinin ve alt türlerinin listesini HTTP referansında bulabilirsiniz.

İstek Yöntemleri

HTTP istek yöntemleri (“eylemler” de denir), kaynak üzerinde gerçekleştirilecek eylemi tanımlar. HTTP, en çok bilinen / kullanılan GET ve POST yöntemleri olan birkaç istek yöntemi tanımlar.

Bir istek yöntemi idempotent veya idempotent olmayabilir. Bu, yöntemin aynı kaynaklarda birkaç kez çağrılmasının güvenli / güvensiz olduğunu açıklayan basit bir terimdir. Başka bir deyişle, bu, yalnızca bilgi alma özelliğine sahip olan GET yönteminin varsayılan olarak idempotent olması gerektiği anlamına gelir. Aynı kaynaktaki GET’in tekrar tekrar çağırılması farklı bir yanıtla sonuçlanmamalıdır. Öte yandan POST yöntemi idempotent bir yöntem değildir.

HTTP / 1.1 öncesinde yalnızca üç yöntem vardı: GET, POST ve HEAD ve HTTP / 1.1’in belirtimi oyuna birkaçını daha getirdi: OPTIONS, PUT, DELETE, TRACE ve CONNECT.

Bu yöntemlerin her birinin ne yaptığını HTTP Referansında daha fazla bulabilirsiniz.

Başlıklar

Başlık alanları, istek veya yanıt mesajının ilk satırından hemen sonra bulabileceği iki nokta üstüste ayrılmış ad-değer alanlarıdır. Bunlar, HTTP mesajlarına daha fazla bağlam sağlarlar ve istemcilerin ve sunucuların, talebin veya yanıtın niteliği hakkında uygun şekilde bilgilendirilmesini sağlarlar.

Toplamda beş tür üstbilgi var:

• Genel başlıklar: Bu üstbilgiler hem sunucu hem de istemci için yararlıdır. İyi bir örnek, mesajın oluşturulma zamanı ile ilgili bilgileri sağlayan tarih başlık alanını içerir.
• İstek başlıkları: İstek mesajlarına özgü. Sunucuya ek bilgi sağlamaktadırlar. Örneğin, Kabul Et: * / * başlık alanı sunucuyu, istemcinin herhangi bir ortam türünü almaya istekli olduğunu bildirir.
• Yanıt başlıkları: Yanıt mesajlarına özgü. İstemciye ilave bilgi sağlarlar. Örneğin, İzin ver: GET, HEAD, PUT üstbilgi alanı, istemciye hangi yöntemlerin istenen kaynak için izin verildiğini bildirir.
• Varlık üstbilgileri: Bu üstbilgiler varlığın gövdesiyle ilgilidir. Örneğin, Content-Type: text / html header, uygulamanın verilerin HTML belgesi olduğunu bilmesini sağlar.
• Genişletme üstbilgileri: Bunlar, uygulama geliştiricileri tarafından oluşturulan standart olmayan üstbilgilerdir. HTTP’nin bir parçası değil, ancak tolere edilmeleri gerekir.

Sıkça kullanılan istek ve yanıt başlıklarının listesini HTTP Referansında bulabilirsiniz.

Durum Kodları

Durum kodu, bir isteğin sonucunu gösteren üç basamaklı bir sayıdır. Bunu, insan tarafından okunabilir olan neden açıklaması takip eder.

Bazı örnekler şunları içerir:

• 200 Başarılı.
• 404 Bulunamadı
• 500 Sunucu Hatası

Durum kodları, beş farklı gruptaki aralıklarla sınıflandırılır.

Hem durum kodu sınıflandırması hem de durum kodlarının tümü ve anlamları HTTP Referansında bulunabilir.

Sonuç

Phew, çok fazla bilgi oldu.

HTTP öğrenerek kazandığınız bilgi, doğrudan bazı problemi çözmenize yardımcı olan tür değildir. Ancak size, HTTP’den daha üst düzeydeki neredeyse her problem için uygulayabileceğiniz internet iletişiminin temel ilkesini anlayacaksınız. İster REST API’ler, web uygulaması geliştirme veya ağ olsun, şimdi bu tür sorunları çözerken en azından biraz daha emin olabilirsiniz.

Tabii ki, HTTP konuşmak için oldukça büyük bir konudur ve hala temel konulardan çok daha fazlası var.

HTTP serisinin 2. bölümünde HTTP’nin mimari yönlerini okuyabilirsiniz.

Bu makale size yardımcı oldu mu? Lütfen yorum bırakın ve bana bildirin.

Bir sonraki ders: HTTP Dersleri – Ders 2 – Mimari Yönleri

Referanslar:

• HTTP / 1.1 belirtimi: http://www.ietf.org/rfc/rfc2616.txt
• HTTP başvurusu: https://www.code-maze.com/the-http-reference
• HTTP: Kesin Rehber: http://shop.oreilly.com/product/9781565925090.do

Orjinal Yazı: https://www.code-maze.com/http-series-part-1/