REST'e genel bakış. Bölüm 2: İstemci ile sunucu arasındaki iletişim

REST'e genel bakış. Bölüm 1: REST nedir? Bu bölümde, bir istemci ile sunucu arasındaki iletişimin nasıl gerçekleştiğini derinlemesine inceleyeceğiz. Yol boyunca yeni terimleri ortaya çıkaracağız ve açıklayacağız. Her şeyin açık olduğundan emin olmak için, örnek olarak bir RESTful uygulaması kullanarak istemci-sunucu iletişimini analiz edeceğiz. Diyelim ki müşteriler ve siparişleri hakkında bilgi depolayan bir web uygulaması geliştiriyoruz. Başka bir deyişle, sistemimiz belirli varlıklar üzerinde işlemler gerçekleştirebilir: bunları oluşturun, düzenleyin, silin ve bunlarla ilgili bilgileri görüntüleyin. Bu varlıklar şunlar olacaktır:

• müşteriler (müşteriler)
• siparişler (müşteri siparişleri)
• öğeler (ürünler)

RESTful bir mimaride, istemciler, verileri almak veya değiştirmek için bir sunucuya istekler gönderir ve ardından sunucular, istemcilerin isteklerine yanıtlar gönderir.

İstekler

İstemci istekleri neredeyse her zaman HTTP protokolü kullanılarak yapılır. Genel olarak, HTTP istekleri birkaç bileşenden oluşur:

• HTTP yöntemi
• başlık
• URI
• istek organı

Aşağıda her bileşeni daha ayrıntılı olarak ele alacağız.

URI'ler ve kaynaklar

İstemcilerin istekler yoluyla aldığı veya değiştirdiği verilere kaynaklar denir. İstemci-sunucu iletişimi tamamen kaynakları manipüle etmekle ilgilidir. REST'te kaynaklar , isim verebileceğiniz her şeydir. Bir anlamda Java'daki sınıflar gibidirler. Java'da her şey için bir sınıf oluşturabiliriz. Yani REST'te bir kaynak herhangi bir şey olabilir: bir kullanıcı, bir belge, bir rapor, bir sipariş. Bir varlığın soyutlaması veya belirli bir şey, örneğin bir resim, video, animasyon veya PDF dosyası olabilir. Örneğimizde 3 kaynağımız var:

• müşteriler (müşteriler)
• siparişler (müşteri siparişleri)
• öğeler (ürünler)

İstemciler, istekleri uç noktalar olarak bilinen kaynak konumlarına gönderir. Basitçe söylemek gerekirse, uç nokta ağdaki bir adres gibidir. Daha derine inerek, uç noktanın bir URI olduğunu söyleyebiliriz., yani soyut veya fiziksel bir kaynağı tanımlayan bir karakter dizisi. Tek tip kaynak tanımlayıcısı (URI) Bazen bir uç nokta veya URI, bir kaynağa giden yol anlamına gelen yol olarak adlandırılır. Bu makalenin amaçları doğrultusunda URI terimini kullanacağız. Her belirli kaynağın benzersiz bir URI'si olmalıdır. Sunucu geliştiricisi, her kaynağın her zaman kendi URI'sine sahip olmasını sağlamaktan sorumludur. Örneğimizde, biz geliştiricileriz, bu yüzden nasıl olduğunu bildiğimiz şekilde yapacağız. İlişkisel bir veritabanında birincil anahtarlar olarak sayısal tanımlayıcılar atamak genellikle alışılmış olduğu gibi, REST'te de her kaynağın kendi kimliği vardır. REST'teki kaynak kimliği, genellikle kaynakla ilgili bilgileri depolayan veritabanındaki kaydın kimliğiyle eşleşir. REST URI'leri geleneksel olarak bazı kaynakları tanımlayan bir ismin çoğul hali ile başlar. Örneğin, "

• /customers — mevcut tüm müşterilerin URI'si
• /customers/23 — Belirli bir müşterinin URI'si, yani kimliği=23 olan müşteri
• /customers/4 — Belirli bir müşterinin URI'si, yani kimliği=4 olan müşteri.

Ama hepsi bu kadar değil. URI'yi emir ekleyerek genişletebiliriz:

• /customers/4/orders — 4 numaralı müşteri tarafından verilen tüm siparişlerin URI'si
• /customers/1/orders/12 — 1 numaralı müşteri tarafından yapılan 12 numaralı siparişin URI'si.

Daha fazla ürün ekleyerek genişletmeye devam edersek şunları elde ederiz:

• /customers/1/orders/12/items — 1 numaralı müşteri tarafından yapılan 12 numaralı siparişteki tüm ürünler listesinin URI'si.

İç içe yerleştirme düzeyleri eklerken, önemli olan URI'leri sezgisel hale getirmektir.

HTTP yöntemi

HTTP yöntemi, kaynakta gerçekleştirilen ana işlemi gösteren herhangi bir karakter dizisidir (kontrol karakterleri ve sınırlayıcılar hariç). Birkaç yaygın HTTP yöntemi vardır. RESTful hizmetlerinde en sık kullanılanları listeleyeceğiz:

• GET - Belirli bir kaynak (kimliği aracılığıyla) veya bir kaynak koleksiyonu hakkında bilgi alın
• POST — Yeni bir kaynak oluştur
• PUT — Bir kaynağı değiştirin (kimliği aracılığıyla)
• DELETE — Bir kaynağı silin (kimliği aracılığıyla)

Başlıklar

İstekler ve yanıtlar HTTP başlıkları içerir. İstek (veya yanıt) hakkında ek bilgi iletirler. Başlıklar, anahtar/değer çiftleridir. En yaygın başlıkların listesini Wikipedia'da görüntüleyebilirsiniz . REST'e gelince, istemciler genellikle sunucuya yapılan isteklerde bir "Kabul Et" başlığı gönderir. Bu başlık, sunucuya, istemcinin hangi biçimde bir yanıt almayı beklediğini söylemek için gereklidir. MIME türleri listesinde çeşitli biçimler verilmiştir. MIME (Çok Amaçlı İnternet Posta Uzantıları), bilgileri kodlamak ve mesajları İnternet üzerinden gönderilebilecek şekilde biçimlendirmek için bir belirtimdir. Her MIME türü, eğik çizgiyle ayrılmış iki bölümden oluşur - bir tür ve alt tür. Farklı dosya türleri için MIME türleri örnekleri:

• metin — metin/düz, metin/css, metin/html
• resim — resim/png, resim/jpeg, resim/gif
• ses — ses/wav, ses/mpeg
• video — video/mp4, video/ogg
• uygulama — uygulama/json, uygulama/pdf, uygulama/xml, uygulama/sekizli akış

Örneğin, bir istek şuna benzer bir başlığa sahip olabilir:

Accept:application/json

Bu başlık, sunucuya, istemcinin JSON biçiminde bir yanıt almayı beklediğini söyler.

İstek gövdesi

Bu, istemci tarafından sunucuya gönderilen mesajdır. İsteğin bir gövdeye sahip olup olmadığı, HTTP isteğinin türüne bağlıdır. Örneğin, GET ve DELETE istekleri genellikle herhangi bir istek gövdesi içermez. Ancak PUT ve POST istekleri, yalnızca isteğin amacına bağlıdır. Sonuçta, (URL'de iletilen) bir kimlik kullanarak veri almak ve/veya silmek için sunucuya ek veri göndermeniz gerekmez. Ancak yeni bir kaynak oluşturmak için (bir POST isteği aracılığıyla) kaynağı göndermeniz gerekir. Aynısı mevcut bir kaynağı değiştirmek için de geçerlidir. REST'te istek gövdesi çoğunlukla XML veya JSON biçiminde gönderilir. JSON formatı en yaygın olanıdır. Yeni bir kaynak oluşturmak için sunucuya bir istek göndermek istediğimizi varsayalım. Eğer unutmadıysan, müşteri siparişlerini yöneten bir uygulama örneğini ele aldık. Diyelim ki yeni bir müşteri yaratmak istiyoruz. Bizim durumumuzda, aşağıdaki müşteri bilgilerini saklarız: Ad, e-posta, telefon numarası. Ardından, isteğin gövdesi şu JSON olabilir:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

İstekleri bir araya getirmek

Bu nedenle, bir müşteri talebinde neler olabileceğini inceledik. Şimdi açıklamalarla birlikte bazı istek örnekleri vereceğiz.

Tepkiler

Sunucu yanıtları hakkında birkaç söz söyleyelim. Bir yanıt genellikle aşağıdaki bölümlerden oluşur:

• cevap kodu
• başlıklar
• yanıt organı

Genel olarak, yanıt başlıkları istek başlıklarından çok farklı değildir. Ek olarak, bazı başlıklar hem yanıtlarda hem de isteklerde kullanılır. Talep organıyla ilgili olarak da her şeyin açık olduğunu düşünüyorum. Vücut genellikle müşteri tarafından talep edilen bilgileri döndürür. GET isteklerine yanıt olarak döndürülen bilgiler de JSON biçiminde olabilir. Ama son kısım biraz daha ilginç.

HTTP yanıt kodları

HTTP yanıt kodlarını daha ayrıntılı olarak ele alalım. HTTP durum kodu, HTTP protokolü aracılığıyla yapılan isteklere verilen sunucu yanıtının ilk satırının bir parçasıdır. Üç ondalık basamaktan oluşan bir tam sayıdır. İlk basamak, yanıt durum kodunun sınıfını gösterir. Yanıt kodunu genellikle bir boşlukla ayrılmış İngilizce açıklayıcı bir ifade takip eder. Bu ifade, yanıt için insan tarafından okunabilen bir nedendir. Örnekler:

• 201 Oluşturuldu
• 401 Yetkisiz
• 507 Yetersiz Depolama

Yanıt kodu, müşteriye isteğin sonucunu söyler ve daha sonra hangi eylemlerin gerçekleştirileceğini belirlemesine olanak tanır. Yanıt kodları birkaç sınıfa veya gruba ayrılır:

• 1XX — Bilgilendirici
• 2XX — Bu kodlar, müşterinin talebinin başarıyla alındığını ve işlendiğini gösterir.
• 3XX — Bu kodlar müşteriye, işlemi başarıyla tamamlamak için genellikle farklı bir URI'ye ek bir istek yapılması gerektiğini bildirir.
• 4XX — İstemci hatası. Bu tür kodlar, yanlış oluşturulmuş bir istekten kaynaklanabilir. Başka bir örnek, iyi bilinen "404 Bulunamadı" kodudur ve bir müşteri var olmayan bir kaynak istediğinde ortaya çıkabilir.
• 5XX — Sunucu hatası. İşlemin başarısızlığından sunucu sorumluysa, bu kodlar istemciye iade edilir.

REST'e genel bakış. Bölüm 3: Spring Boot'ta RESTful bir hizmet oluşturma