İlk modül, bir HTTP isteği oluşturmanız, göndermeniz ve bir yanıt almanızla sona erdi.

Bunu gelecekte birçok kez daha yapacağız. İstekleri üçüncü taraf sunuculara göndereceğiz. Bu tür talepleri kabul eden ve yanıt veren başvurular yapacağız. İstekleri işlemek için karmaşık bir mantık oluşturacağız.

Bu nedenle, bu taleplerle ilgili her şeyi iyice incelemek, detaylı bir şekilde analiz etmek iyi olacaktır. Böylece isteği bir yere kopyalayıp tekrar edemezsiniz, bunun nasıl çalıştığını gerçekten anlayabilirsiniz.

İkinci modülde yapacağımız şey bu. Hadi gidelim!

Teori ile başlayalım.


REST API'sini Öğrenme

REST API temelleri

İlk modülde ödevinizi yaptıysanız ve belgeleri incelediyseniz, kısaltma API'sini fark etmiş olmalısınız. Aslında, ağdaki bir hizmet veya uygulama ile etkileşimi anlamak istiyorlarsa geliştiricilerin incelemesi gereken ilk şey API belgeleridir.

API - Uygulama Programlama Arayüzü. Bu, istemci ve sunucunun birbirleriyle iletişim kurma yollarının bir açıklamasıdır. API belgelerini açıyoruz ve oradan gerekli verilerin sunucudan nasıl alınacağını öğreniyoruz.

Bu etkileşimin her zaman basit ve anlaşılır olmasını isteriz. Bu, hem geliştiriciler (yeni bir hizmet tasarlarken tekerleği yeniden icat etmeye gerek yoktur) hem de kullanıcılar (önceden bilinen hizmetlerle aynı prensipte çalışıyorsa bir hizmetin öğrenilmesi çok daha kolay) için görevi basitleştirir. Ve burada yeni bir terimi hatırlamaya değer - REST.

REST - Temsili Durum Transferinin kısaltması. Kulağa çok net gelmeyebilir, ancak basitçe söylemek gerekirse, REST, bir istemci ve bir sunucu arasındaki bir etkileşim (bilgi alışverişi) tarzıdır.

Bu, katı kurallar ve gereksinimler dizisi değildir. REST, belirli bir programlama dilinin kullanımını zorlamaz ve katı yönergelerle elleri bağlamaz. REST bir mimari stil olarak adlandırılır ve bir sistem mimarisinin uyması gereken 6 ilkeyi tanımlar.

Buna göre, REST ilkeleri dikkate alınarak geliştirilen bir API'ye REST API , uygulamaların kendilerine ise RESTful adı verilir.

Tam da böyle RESTful uygulamalar oluşturacağız, bu yüzden hemen uyum sağlayacakları ilkeleri tartışmaya değer.

  1. İstemci-Sunucu Modeli. İlke, istemci ve sunucunun ayrılmasını, ihtiyaçlarının farklılaşmasını tanımlar. Müşterinin verilerin nasıl saklandığı konusunda endişelenmesine gerek yoktur, asıl mesele, talep üzerine verilmesidir. Buna karşılık, sunucu, istemcinin bu verilerle ne yapacağını, nasıl daha fazla işlenip görüntüleneceğini umursamıyor. Bu, birbirlerinden bağımsız olarak gelişmelerini sağlar ve sistemin ölçeklenebilirliğini artırır.
  2. Vatansızlık. Bu ilke, sunucunun, bu istemciyle daha önceki deneyimlere dayanarak yanıtı "düşünmemesi" gerektiği anlamına gelir. Herhangi bir talep, önceki taleplerden bağımsız olarak işlenmesi için gerekli tüm bilgileri içerecek şekilde yapılır.
  3. Önbelleğe almak. İletilen verileri en aza indirmek için bir önbellek mekanizması vardır. Örneğin, bir sayfada bir logo görüntüleniyorsa, bunu her seferinde sunucudan talep etmenin bir anlamı yoktur. Çok sık değişmez, bir kez alıp müşterinin bilgisayarına, önbelleğe kaydetmeniz yeterli olacaktır. Ancak arabanın mevcut hızı hakkında bilgi almamız gerekirse, önbellek hiçbir şekilde yardımcı olmaz. Bu ilke, sunucu tarafından iletilen verilerin önbelleğe alınabilir olup olmadığını belirlemektedir.
  4. Üniforma arayüzü. İlke, istemci-sunucu etkileşiminin tek bir biçimini tanımlar. Tüm isteklerin yapısı aynı olmalıdır. Veriler, kimin talep ettiğinden bağımsız olarak aynı biçimde gönderilmelidir.
  5. Katmanlı Sistem. İstemci ve sunucunun doğrudan iletişim kurması gerekmez. Veri iletimi birkaç ara düğümden geçebilir. Bu durumda, sistem, ne istemci ne de sunucu, son uygulama veya bir ara düğüm ile etkileşime girip girmediklerini bilmeyecek şekilde tasarlanmıştır. Bu, sunuculardaki yükü dengelemenize, ölçeklenebilirliği artırmanıza olanak tanır.
  6. İsteğe bağlı kod (isteğe bağlı) . Zorunlu olmayan tek ilke. Buna göre, istemci, sunucudan yürütülebilir kod (örneğin, komut dosyaları) indirerek işlevselliğini genişletebilir. Bu durumda, kod yalnızca talep üzerine yürütülmelidir.

Çok fazla teori değil mi?

Bunu uygulamaya koyalım.

API isteği oluşturma

AppMaster'ı açalım , onu kullanarak bir API isteği oluşturalım ve bu isteğin nasıl çalıştığını daha iyi anlayalım.


API istekleri, "Harici API İstekleri" sekmesindeki "İş mantığı" bölümünde oluşturulur.

“+ Yeni API İsteği”ne tıklamanın zamanı geldi.


İsim ve açıklama herhangi bir şeye ayarlanabilir, bunlar sadece bizim kişisel kullanımımız içindir.

Gerçekten önemli olan verilerle ilgilenelim.

Bir istek oluşturmak için gereken minimum, Yöntemini ve adresini (URL) belirtmektir. Sonuncusuyla başlayalım.


URL - Tekdüzen Kaynak Bulucu. İnternette belirli bir kaynağa verilen adres. Böyle bir kaynağın en tanıdık sürümü bir HTML sayfasıdır - URL'sini tarayıcının adres çubuğuna girip istenen siteyi açıyoruz. Aynı zamanda, kaynağın kendisi herhangi bir şey, bir resim, bir video, bir veri seti olabilir. Ana şey, bu kaynağın belirli bir işaretçisi olmasıdır - bu kaynağı almak için istek gönderebileceğiniz bir URL.

Adresindeki verilere atıfta bulunarak, isteğin yöntemini de (türünü de söyleyebilirsiniz) belirtiyoruz, yani bu verilerle gerçekte ne yapılması gerektiğini belirtiyoruz.

İlk modülün görevi için istek gönderdiğimizde veri aldık. Bu GET yöntemidir. Bu yöntem en belirgin yöntemdir ve aynı zamanda gerekli olan tek yöntemdir. Bu nedenle, açıkça belirtmemiş olsak bile, varsayılan olarak bunun GET olduğu varsayıldı.

Bakalım başka hangi yöntemler var.


HTTP standardının kendisi kullanılabilecek yöntemlerin sayısını sınırlamaz. Aynı zamanda, uyumluluğu korumak için hala en standart yöntemlerden bazıları kullanılmaktadır. AppMaster API isteklerinde kullanılabilecek 5 farklı yöntem vardır.

  • GET . Zaten halledilir. Yöntem, bir kaynağın sağlanmasını ister ve verileri alır.
  • POST . Bir yerden veri almak için önce bu veriyi oraya yerleştirmeniz gerekir. POST yöntemi tam da bunu yapar. Sunucuya veri gönderir, bir kaynak oluşturur.
  • KOY . POST yöntemine benzer, ancak görevi verileri güncellemektir. Yeni veri oluşturmaz, mevcut verileri değiştirir, günceller.
  • SİL Adından da anlaşılacağı gibi, verileri siler.
  • yama . Yöntem PUT'a benzer, ancak verileri tamamen değiştirmek yerine kısmen güncellemek için kullanılır. Örneğin, PATCH yöntemini kullanarak bir makalenin başlığını değiştirebilir veya bazı parametrelerin değerini değiştirebilirsiniz.

Sunucunun yöntemde belirtilenleri tam olarak yapması gerekmediği gerçeğini dikkate almak önemlidir. DELETE yöntemiyle bir sayfanın adresini gönderebiliriz ancak bu, sunucunun onu gerçekten sileceği anlamına gelmez. Ancak, tamamen teorik olarak, bunu GET komutuyla yapabilir. Veya hiçbir şeyi değiştirmeyin, aynı zamanda POST'a yanıt olarak veri gönderin. Sadece geliştirici bu şekilde yapılandırdığı için.

İşte burada REST devreye giriyor, bu da siparişe uyulması konusunda anlaşmanın, karışıklığı durdurmanın ve yöntemde tam olarak belirtilenleri yapmanın zamanının geldiğini söylüyor. En azından ana görev bu olmalıdır (her ne kadar tek görev olmasa da). Örneğin, bir makalenin içeriğini GET yöntemini kullanarak aktarırken, aynı zamanda görüntüleme sayısının sayacını 1 artırabilirsiniz.

Böylece verilerin nerede olduğunu ve onunla neler yapılabileceğini anladık. Daha ileri gidelim, isteğin başka hangi bileşenlerine sahip olabileceğini görelim.


URL Parametreleri. URL'nin yalnızca bir kısmını bildiğimiz durumlar vardır. Bir örnek, Appmaster.io web sitesindeki makalelerdir. Tüm makalelerin başlangıç ​​adresi aynıdır - https://appmaster.io/en/blog/. Ancak her makalenin kendi başlığı ve buna bağlı olarak bu makalenin tam olarak belirtilmesi için kendi bireysel bölümü vardır.

Böyle bir durumda URL Paramları kullanılır. Genel kısmı hemen yazıyoruz ve gerisini süreçte karar vermeye bırakıyoruz. Sonuç olarak, URL https://appmaster.io/ru/blog/:id/ biçiminde yazılır.

Bilinen kısım olduğu gibi yazılır ve değişken kısım “:” işaretinden sonra yerleştirilir. Bu değişken parçasının adı (zaten “:” olmadan) parametre listesine eklenir. Bu durumda, birkaç değişken parça olabilir ve bunların konumu URL'de herhangi bir yerdedir.


Sorgu Parametreleri . İlk modülde can sıkıntısı.com'a istek gönderdiğimizi hatırlıyor musunuz? Ve adrese ek olarak, ek veriler reçete edildi. Sorgu Paramları buydu.

URL'den sonra yazılırlar ve URL'den bir "?" ile ayrılırlar. işaret. Parametrenin adı, “=” işareti ve parametrenin kendisinin değeri belirtilir. Aynı anda birden fazla parametre kullanılıyorsa, bunlar “&” işaretiyle ayrılır.

Ancak AppMaster'da parametreleri belirlerken istek kurallarını düşünmeniz gerekmez. Her şey otomatik olarak uygun şekilde biçimlendirilecektir. Parametrenin adını belirtmeniz ve listeye eklemeniz yeterlidir.

Sorgu Paramları, veri kaynağı aynı olduğunda kullanılır, ancak verilerin kendisi farklı olabilir. Örneğin, Boredapi'de yapılacak çok şey var. Ancak yalnızca bir kişiye yönelik olanlarla ilgilendik ve istek parametrelerinde belirttiğimiz şey buydu.

Başka bir seçenek bir erişim anahtarıdır. Alphavantage'a atıfta bulunurken bu seçeneği modül 1'de kullanmış olabilirsiniz. Veriler ancak kayıt olduktan ve istek parametrelerinde kişisel bir anahtar gönderdikten sonra elde edilebilir.

İnternette ziyaret ettiğiniz sayfalara dikkat edin, muhtemelen onlarda da çeşitli parametreler bulacaksınız. Örneğin, Ventusky.com'un hava durumu sayfasını açın, sorgu parametrelerinde enlem ve boylamın coğrafi değerleri gönderilir.

Başlıklar . Başlıkları isteyin. Genellikle başlıklar, istekle ilgili hizmet bilgilerini içerir (meta-bilgi). Başlıklar, sunucunun verileri isteyen istemci hakkında daha fazla bilgi almasına izin verir. Başlıklar, hangi tarayıcının kullanıldığı, yanıtın hangi kodlamada olması gerektiği, hangi dilde, isteğin tam zamanı ve daha fazlası hakkında bilgi içerebilir. Korunan verilere erişim durumunda, başlıklar bir yetkilendirme anahtarı içerebilir.

Çoğu durumda, başlıklar isteğe bağlıdır. İlk modülde bile, herhangi bir başlık belirtmediğimiz bir istekte bulunduk (ancak bu, isteğin aslında onlarsız gönderildiği anlamına gelmez).

vücut . Beden iste. GET istekleri genellikle onsuz yapılır, ancak sunucuya bazı veriler göndermek, bir POST veya PUT isteği göndermek istiyorsak, bu veriler istek gövdesine yerleştirilir. Aynı zamanda, istek gövdesine herhangi bir karmaşıklıktaki verileri yerleştirebilir, örneğin bir video dosyası gönderebilirsiniz ve bir sayı veya metin dizesiyle sınırlı değildir.

Sunucudan gelen Yanıt hemen hemen aynı şemaya göre çalışır. Açık nedenlerden dolayı, istek parametresi yoktur, ancak Başlıklar ve Gövde cevaba dahil edilmiştir (boş olsalar da).

Önemli bir fark, yanıtın durumudur.

Durum kodu . Sunucu yanıtının ilk satırında gelir. Durum, üç basamaklı bir sayıdır (kodun kendisi), ardından onu açıklayan bir ifade gelir.

İsteğin sonuçları hakkında bilgi edinebileceğiniz ve daha sonra hangi işlemlerin yapılması gerektiğini anlayabileceğiniz durum kodudur.

Tüm olası durum kodları 5 sınıfa ayrılmıştır. Kodun ilk basamağı belirli bir sınıfa ait olduğunu belirler. Hadi onları parçalayalım.

1xx — bilgi kodları. İsteğin ilerleme durumunu bildirin. Gerçek uygulamada, nadiren kullanılırlar.

2xx — başarı kodları. Her şeyin yolunda olduğunu ve talebin başarıyla tamamlandığını bildirdiler. Bir GET isteğine yanıt olarak, genellikle 200 (OK) kodu almayı bekleriz. Başarılı bir PUT isteği, bir 201 (Oluşturuldu) kodu gönderir.

3xx - yönlendirmeler. İsteğin farklı bir adrese gönderilmesi gerektiğini belirtin. Bir örnek kod 301'dir (Kalıcı Olarak Taşınır), gerekli verilerin artık yeni bir adreste olduğunu gösterir (yeni adresin kendisi Konum başlığında iletilir).

4xx — istemci hata kodları. Bunların en ünlüsü - 404 (Bulunamadı), belirtilen adreste gerekli veri olmadığını bildiriyor. Diğer yaygın durumlar: 400 (Kötü İstek, istekte sözdizimi hatası), 401 (Yetkisiz, erişim için kimlik doğrulama gerekli), 403 (Yasak, erişim reddedildi).

5xx — sunucu hata kodları. Sunucu tarafında bir hata bildirin. Örnek olarak: 500 (Dahili Sunucu Hatası, bilinen kodla ilişkilendirilemeyen herhangi bir anlaşılmaz hata), 503 (Hizmet Kullanılamıyor, sunucu teknik nedenlerle geçici olarak isteği işleyemiyor)

Bu noktada, REST API ve HTTP istek ve yanıtlarının yapısını anlamak için temel bilgileri ele aldığımızı varsayabiliriz. Sadece bir noktayı netleştirmek için kalır - veri türleri. API isteğinizi AppMaster'da zaten oluşturmayı denediyseniz, muhtemelen tüm verilerin (parametrelerde, başlıklarda, gövdede) sizden yalnızca adı değil aynı zamanda veri türünü de belirtmenizi istediğini fark etmişsinizdir.


Belirli bir bağlam olduğu için, genellikle bir insan için verilerle nasıl çalışılacağı oldukça açıktır. 2 + 2 = 4 olduğunu bildiğimizi varsayalım. Bunların sayı olduğunu ve toplama işleminin sonucunun başka bir sayı olacağını tahmin ediyoruz.

Ancak sayılar değil, metinsel veriler olabilir. Daha sonra bunların eklenmesinin sonucu dizilerin birleşmesi olabilir ve 2 + 2 "22"ye dönüşür. Burada, bilgisayarın hiçbir şey düşünmesine gerek kalmaması için, veri türünün kesin bir göstergesi vardır. Ve aynı zamanda, diğer görevler çözülüyor. Örneğin, yanlış veri girilmesine karşı koruma sağlanır; başlangıçta, bir telefon numarasının numaralarını girmek için tasarlanan alana bir e-posta adresi kaydetme imkanı yoktur.

Oldukça fazla farklı veri türü var, şimdi en temel olanları ele alacağız ve kursun sonraki modüllerinde geri kalanıyla tanışacağız.

Dize — Dize veri türü, özel biçimlendirme içermeyen düz metin.

Tamsayı — Tamsayı veri türü. Kesirli sayıların gerekli olmadığı sayaçlar veya hesaplamalar için kullanılabilir

Float — Kayan nokta numarası. Arttırılmış hassasiyetin gerekli olduğu ve tamsayı değerlerinin yeterli olmadığı durumlarda kullanılır.

Burada mantıklı bir soru ortaya çıkabilir. Ve neden her zaman Float kullanmıyorsunuz, o zaman neden Integer'a ihtiyacımız var? Ancak daha fazla doğruluk, daha fazla kaynak gerektirir. Bazı küçük hesaplamalar için bu tamamen görünmez olabilir, ancak büyük miktarda veri olması durumunda, makul bir veri türü kullanmak, bilgi işlem gücü ve disk alanı gereksinimlerini önemli ölçüde azaltabilir.

Boolean — boolean veri türü. En basit veri türü. True veya False olarak yazılan iki değerden birini alır. Tanımlamayı genellikle 1 (doğru) ve 0 (yanlış) şeklinde görebilirsiniz.


Ev ödevi

Ev ödevinden ilk modüle kadar olan istekleri, Harici API İstekleri bölümünde AppMaster'da oluşturarak tekrarlayın.

  1. BoredAPI'ye bir istek oluşturun. Belgelerden en az 5 farklı parametre belirtin. Yalnızca gerekli parametreleri belirterek birkaç farklı istek gönderin.
  2. Alphavantage'a bir istek oluşturun. Birbirlerine göre farklı para birimlerinin oranlarını almak için parametreleri kullanın.