Bu makale bu mimarinin temellerini, olanaklarını ve uygulamalarını açıklamaktadır.

REST nedir?

REST seçeneği, herhangi bir ek dahili işleme gerek kalmadan bilgileri yönetmek için çok basit bir arayüze sahiptir. Her bilgi parçası, URL gibi genel bir tanımlayıcıyla benzersiz bir şekilde tanımlanır. Her URL'nin kendine özgü bir görev biçimi vardır.

Ve şimdi en açık şekilde:

Ek dahili aramaların varlığı, verilerin kendisi ile aynı şekilde aktarılması anlamına gelir. Tobto. SOAP ve XML-RPC'de olduğu gibi verileri XML'e yazmıyoruz, Flash vb. gibi AMF kullanmıyoruz. Biz sadece verinin kendisini veriyoruz.

Her bilgi parçası bir URL ile benzersiz bir şekilde tanımlanır; bu, URL'nin bilgi parçası için birincil anahtar olduğu anlamına gelir. Tobto. örneğin polis kitabındaki üçüncü kitap /kitap/3'e, bu kitaptaki 35. sayfa ise /kitap/3/sayfa/35'e benziyor. Zvіdsi ve görev biçiminden çıkın. Ayrıca, /book/3/page/35 adresindeki verilerin hangi formatta bulunduğu hiç önemli değildir - bu HTML, jpeg dosyası olarak taranmış bir kopya veya bir Microsoft Word belgesi olabilir.

Bilgilerin hizmet tarafından nasıl yönetileceği tamamen aktarım protokolüne bağlıdır. En gelişmiş protokol elbette HTTP'dir. Yani HTTP için veri üzerindeki eylem şu yöntemlerle belirlenir: GET (kaldır), PUT (ekle, değiştir), POST (ekle, değiştir, sil), DELETE (silinmiş). Böylece CRUD (Create-Read-Updtae-Delete) işlemleri GET ve POST dahil olmak üzere istenilen sayıda yöntem kullanılarak tamamlanabilmektedir.

Aks, popo üzerinde göründüğü gibidir:

GET /book/ - mevcut tüm kitapların listesini alır
GET /book/3/ - 3 numaralı kitabı al
PUT /book/ - kitap ekle (kullanıcıdan gelen veriler)

DELETE /book/3 – kitabı görüntüle

ÖNEMLİ EKLEME: Bunlara, kırılması gereken HTTP yöntemleriyle ilgili olan REST Kalıpları adı verilir. Eve daha yakın olan farklı modeller, POST ve PUT'a farklı şekillerde bakar. Ancak PUT, oluşturma, yeniden oynatma ve güncelleme için atanmamıştır ancak POST için bir atama yoktur (POST işlemi çok geneldir ve ona özel bir anlam yüklenemez). Dolayısıyla benim örneğim bu formda doğru olacaktır ve sanki POST ve PUT'u birbirinin yerine kullanıyormuşsunuz gibi.

Bir kez daha POST tüm değişiklikler için aynı anda değiştirilebilir:
POST /kitap/ – kitap ekle (veri isteniyor)
POST /book/3 – kitabı değiştir (veriler istenecektir)
POST /book/3 – kitabı sil (gövde boş olacak)

Bu, bazen PUT ve DELETE sorunlarıyla ilişkili hoş olmayan anları görmezden gelmenize olanak tanır.

Günlük Web hizmetleri için REST wiki.

Cilt bilgi birimi için 5 eylem belirtilmiştir. Ve kendine:

Bilgi almak/ (Dizin)- Tüm nesnelerin bir listesini görüntüler. Bağışlanmayı çağır, hepsi bu. Başka veriler olmadan yalnızca tanımlayıcı ve nesne adı alanlarını yerleştirin.

GET /bilgi/(kimlik) (Görüş)- Nesne hakkında daha fazla bilgi alır.

PUT /bilgi/ ya da başka POST /bilgi/ (Yaratmak)- Yeni bir nesne yaratıyorum. Veriler vücutta herhangi bir resmi kodlama olmaksızın urlencode kullanılarak iletilir. PHP'de gövde şu şekilde yazılabilir:

getBody() işlevi (
if (!isset($HTTP_RAW_POST_DATA))
$HTTP_RAW_POST_DATA = file_get_contents("php://input");
$HTTP_RAW_POST_DATA değerini döndür;
}

POST /bilgi/(kimlik) ya da başka PUT /bilgi/(kimlik) (Düzenlemek)– verileri tanımlayıcı (id) ile değiştirir, muhtemelen bunların yerine geçer. Veriler ayrıca isteğin gövdesinde de iletilir, ancak PUT modunda önemli bir nüans vardır. Sağda, POST isteği urldecoded-post-data'nın varlığını iletir. Tobto. Kodu sabit tutmazsanız standardı ihlal etmezsiniz. Burada kimi isteseler standarda saygı göstermiyorlar, sanki değişim sonrasıymış gibi vikoristlik yapıyorlar.

SİL /bilgi/(kimlik) (Silmek)– tanımlayıcıdan (id) verileri siler.

/info/ uygulamamızda, URL'de görüntülenebilen (ve gösterilebilecek) diğer bilgilere dayanabileceğini bir kez daha belirtmek isterim:

/data/4/otherdata/6/info/3/ … işte bu kadar.

Bu konseptten neler kazanabilirsiniz:

Görünüşe göre REST mimarisi geliştirme açısından çok basit. Komut istemine bakarak, formatları (SOAP, XML-RPC için) anlamadan ne çalıştığını anlayabilirsiniz. Veriler, ek veriler depolanmadan aktarılır; bu nedenle, ne yapılacağını anlamak için ayrıştırma gerektirmediği ve verileri bir formattan diğerine aktarmayı gerektirmediği için REST, daha az kaynak yoğun olarak kabul edilir.

Durgunluktan daha pratik.

REST mimarisi, görevi ciddi şekilde basitleştirmenize olanak tanır. Bu özellikle işlevsellik açısından doğrudur, ancak çok az açıklama vardır ve birine bilgileri değiştirme yeteneği vermek mümkün olmasa bile, yetkilendirme ve kimlik doğrulama da gereklidir. Bu, başka herhangi bir oturum türü veya yalnızca HTTP Kimlik Doğrulaması kullanılarak kolayca yapılabilir.

REST API (Temsili Durum Transferi) veya RESTful web hizmetleri nedir? REST, İngilizce'den "stan'a temsili aktarım" olarak çevrilmiştir. Bu, internetteki bilgisayar sistemleri arasındaki etkileşimi sağlamanın bir yöntemidir. Metin tabanlı web kaynaklarını tüketen, bunlara erişimi engelleyen ve bunları işleyen sistemlere, vikoryst'e ve tümleşik işlemlere olanak tanıyan REST tabanlı web hizmetleri. Güçlerini WSDL ve SOAP gibi ek işlem kümeleriyle birleştiren diğer web hizmetleri biçimlerini keşfedin.

REST API: nedir bu? Anladım

Web kaynakları öncelikle World Wide Web'den URL'leriyle tanımlanan belgeler veya dosyalar olarak tanımlanır. Bugünün kokusu, Merezhi'de tanımlanabilen, isimlendirilebilen, adreslenebilen ve toplanabilen ten nesnesini ve gerçekliği koklayan daha belirsiz ve soyut bir anlam olabilir. REST API web hizmeti, XML, HTML, JSON veya başka herhangi bir biçimde biçimlendirilebilen bir URI kaynağında bir yanıt ister. Kaydedilen kaynakta değişiklik yapıldığını onaylayabilir ve hiper metin mesajlarını diğer ilgili kaynaklara ve bunların koleksiyonlarına iletebilirsiniz. En genişletilmiş protokol olan HTTP'nin kullanımı, PUT, DELETE, HTTP GET, POST komutlarıyla belirtilen mevcut işlem türlerini kapsar.

Düzenleme olmadan zafer protokolleri standart operasyonlar haline gelecek, REST sistemleri sisteme müdahale etmeden işlenebilen ve güncellenebilen re-vikoristik bileşenlerin sayısını artırmak için yüksek verimlilik, güvenilirlik ve kullanılabilirlik hedefleniyor. REST web siteleri, SOAP (Basit Nesne Erişim Protokolü) tarzında genellikle daha basit ve daha az önemlidir; REST ağları ise aynı bant genişliği maliyetlerine sahip değildir, bu da onları İnternet'teki web siteleri için daha uygun hale getirir. SOAP yaklaşımı için, bir sunucu programı (verilere hizmet vermek için) ve bir istemci programı (verileri depolamak için) yazmanız veya oluşturmanız gerekir.

Teknolojinin tarihi

"Ülkeye temsilci transferi" terimi, 2000 yılında Roy Fielding tarafından "Mimari stiller ve uç yazılım mimarilerinin tasarımı" adlı tezinde tanıtıldı ve icat edildi. REST'in mimari tarzını HTTP 1.1 1996-1999'a paralel olarak, HTTP 1.0 1996 ana projesini temel alarak geliştirdik. Teknolojinin gelişimine geriye dönük bir bakış sunan Fielding, HTTP standardizasyonu sürecinde internetteki tasarım tercihlerinin çalınmasının muhtemel olduğunu söyledi. Bu, İsveç'in nasıl bu galusanın merkezi haline geleceği konusunda herkesten teklif kabul edilen süreç çerçevesinde daha karmaşık bir süreç.

Birçoğu kapsamlı bilgi birikimine sahip özel mühendisler olan 500'den fazla katılımcının yorumları besleniyor. Web etkileşimlerinin soyut anlayışından HTTP sözdiziminin kesin ayrıntılarına kadar her şeyi açıklamak size kalmıştır. Bu süreç, bu modeli artık REST olarak adlandırılan bir dizi temel ilke, ilke ve çerçeveye dönüştürdü.

Avantajları

REST stilinin özellikleri aşağıdaki mimari ilkelerden kaynaklanmaktadır:

• Verimlilik – üretkenlik ve etkililik önlemlerinin yönetiminde bileşenlerin ve hakim otoritelerin etkileşimi.
• Maksimum sayıda bileşeni destekleyecek, REST API'lerini ve aralarındaki etkileşimleri test edecek ölçeklenebilirlik.
• Tek bir arayüzün basitliği ve REST API yetkilendirmesi.
• Belirli ihtiyaçları karşılamak için bileşenlerin değiştirilmesi (çalıştırma programlarına göre).
• Depo ve servis temsilcileri arasındaki iletişimin görünürlüğü.
• Program kodlarını verilerle taşıyan bileşenleri taşıma yeteneği.
• Güvenilirlik - Depoda arıza, bağlantı kopması veya veri olması durumunda arızaya karşı yüksek direnç.

İstemciler arasındaki sorunların kapsamı, REST API'nin bileşenlerin uygulanmasını hissetmenize olanak sağlaması, bağlayıcının anlambiliminin karmaşıklığını değiştirmesi, üretkenliği ayarlama verimliliğini artırması ve saf sunucu bileşenlerinin ölçeklenebilirliğini desteklemesi ile açıklanmaktadır iv. Kompakt sistem ara bağlantıları, aracıların (proxy'ler, ağ geçitleri ve güvenlik duvarları), bileşenler arasındaki arayüzleri değiştirmeden farklı noktalarda iletişim kurmasına olanak tanır, bu da onların büyük ölçekli zagalny keshuvannya'nın yardımıyla REST aktarımı gerçekleştirmelerine veya Vati üretkenliğini aktarmalarına olanak tanır. REST API'nin uygulanması, etkileşimin istekler şeklinde olmaması durumunda, anlambilimi ve bilgi alışverişini tanımlamak için standart yöntemlerin ve medya türlerinin kullanılması ve sonuçların açıkça önbelleğe almayı göstermesi gerçeğinden kaynaklanmaktadır.

Biçimsel ve mimari sınırlar

Altı temel sınır RESTful sistemini karakterize eder. Sunucunun istemcilerden gelen istekleri işleme ve alma yollarını tanımlarlar. Bu etkileşimler çerçevesinde hareket eden hizmet, verimlilik, ölçek, basitlik, bolluk, görünürlük, hareketlilik ve güvenilirlik gibi işlevsel olmayan güç unsurlarını ortadan kaldırır. Hizmet gerekli bağlantıları keserse RESTful olamaz.

İlk sınırlar istemci-sunucu mimari tarzına getirilir. İstemci arayüzündeki sorunların ve veri kaydetme sorunlarının azaltılması, istemci arayüzünün çeşitli platformlarda taşınabilirliğini artıracaktır. Ayrıca sunucu bileşenlerini basitleştirerek ölçeklenebilirliği artırır. Merezha için belki de en önemlisi, bileşenlerin bağımsız olarak gelişmesine izin vermesi ve böylece İnternet ölçeğinde büyük organizasyonel alanlara olanak sağlamasıdır.

Emniyet

REST gerekli güvenlik desteğini sağlamaz. Bu özellikle REST web hizmetlerini tasarlarken önemlidir; güvenlik ve tasarımın dikkate alınması gerekir. REST web hizmetleri, CRUD işlemleriyle HTTP PUT ve DELETE kullanır. PUT ve DELETE birçok tarayıcı tarafından desteklenmez ve gizliliği tehlikeye atma olasılığı nedeniyle çoğunlukla eş sunuculara bağlanır. Sunucu ile istemci arasında uygun bir kurulum yoksa herhangi bir üçüncü taraf istemci, PUT yöntemini kullanarak veya farklı bir DELETE kaynağı kullanarak kaynak oluşturabilir. Geliştirme döneminde web servislerinin güvenliğini sağlamak ve bu anların korunmasını sağlamak mümkün oldu.

Mimari elemanlar

REST'in önemli bir yönü, veri öğelerinin doğasıdır. REST stili, bilginin davranışını ve üretimini tanımlayan çeşitli kavramlara sahiptir.

Kaynak, internette mevcut olan bir nesnedir (mantıksal veya fiziksel). Bu, sunucu dosya sisteminde saklanan bir belge veya veritabanı tablosundaki bir satır olabilir. Terminal koristuvach, şarkı işaretine ulaşmak için kaynakla etkileşime girer. REST kullanarak bir sistem tasarlamak için tasarımcının iş nesnelerini kaynaklar ve ele alınabilecekler olarak düşünmesi gerekir.

URI – bir kaynağı benzersiz şekilde tanımlar. Bu parametre adres kaynağını değiştirir ve değişebilir. Kaynaklar, HTTP gibi protokol destekli programlarla değiştirilir.

Podannya - Şu anda bir kaynak olacağım. İstemci, isteği URI'nin ardından kaynağa döndürür. Kaynak, iletilen XML, HTML, JSON, RSS, REST API java gibi bir veya daha fazla formatta görüntülenebilir. Bu formatlara içerik geliştirme için ek bir mekanizma eklenebilir.

Yetki - programın bir durumdan diğerine geçişi iptal etmesine olanak tanır. Her kaynağın diğer kaynaklarla bağlantıları olabilir. Şimdiki durum yaklaşan geçişin yasalaşmasını doğrulayabilir. İyi bağlanmış bir program, kullanıcının arayüzü bağımsız olarak açmasına olanak tanır.

Bağlayıcı

Bağlantı, bileşenler arasındaki bağlantılara aracılık eden soyut bir arayüzdür. REST etkileşiminin parçaları silinmez; bağlayıcı, ağ hakkındaki bilgilerin kaydedilmesinden sorumlu değildir. Bu nedenle bileşenler arasındaki bağlantılar paralel olarak oluşturulabilir.

İstemci ve sunucu ana REST bağlayıcılarıdır. İstemci isteği başlatır ve sunucu bunu işler.

Nakit roz'emlerin bir başka türüdür. Önbelleğe alma istemci, sunucu ve diğer düzeylerde uygulanabilir. Bu, iyileşme saatini ve sınırların yakınlığını değiştirir.

Bileşenler

Bileşenler, üretimin ve transfer tesisinin depolanması için koşullar yaratan, kesin olarak tanımlanmış kaynak yöntemleri kullanılarak birleştirilir.

Kullanıcı Aracısı – bir isteği başlatmak için vikoryst istemci bağlantısı.

Origin-server – Güç kaynağı için Vikorist sunucu konektörü.

Proxy, istemci tarafında arayüzü diğer hizmetlerle kapsüllemek için kullanılan bir aracıdır. Aynı zamanda verilerin çevrilmesini ve korunmasını da içerir.

Ağ geçidi, arayüzün diğer hizmetler tarafından kapsüllenmesini sağlamak için sunucuya kurulan bir aracıdır.

Gelişim beklentileri

Yeni alakalı yiyecek: REST API - mevcut İnternet teknolojileri için nedir? REST, mevcut birkaç stilin analiz edilmesi ve bunlara yeni eklemeler yapılmasıyla geliştirilen modern web mimarisinin temelidir.

REST API'nin Hedefleri - nedir? Amaç, çapraz karışmayı en aza indirmek ve ölçeğe ulaşmak için bileşenlerin bağımsız gelişimini en üst düzeye çıkarmak için farklı stilleri koordineli bir sınır kümesiyle birleştirmektir. Yeni hipermedya mimarisinin fiyatı. Akıllı telefonların, tabletlerin ve cihazların ortaya çıkışıyla birlikte bir ölçek ölçüsü de ortaya çıktı.

Üçüncü taraf hizmetler için RESTful API oluşturulabilir. Tek taraflı robot programlarını arka uçla kullanabilirsiniz. Arayüzü tasarlamadan önce bilmeniz gereken bir takım önemli noktalar vardır.

URL'ler ve koşullar

REST'in temel ilkesi API'nizi mantıksal kaynaklara bölmektir. Bu kaynakların yönetimi, standart bir yöntemle (GET, POST, PUT, PATCH, DELETE) ek HTTP istekleri kullanılarak gerçekleştirilir.

Kaynak çokluğun adıyla tanımlanmalıdır. Kaynaklar üzerindeki eylemler CRUD stratejisi kullanılarak tanımlanır ve HTTP yöntemleri tarafından aşağıdaki sırayla desteklenir:

• GET /api/users – istemcilerin listesini alır;
• GET /api/users/123 - belirtilen kullanıcıyı seçin;
• POST /api/users – yeni bir kullanıcı oluşturun;
• PUT /api/users/123 - belirtilen hesap yöneticisinin tüm ayrıntılarını güncelleyin;
• PATCH /api/users/123 – koristuvach'ın verilerini kısmen güncelleyin;
• DELETE /api/users/123 - vidalıti koristuvach.

Bir kaynak yalnızca başka bir kaynağın bağlamında mevcut olduğundan URL birleştirilebilir:

• GET /api/posts/9/comments - yorum listesini 9 numaralı girişe doğru kaydırın;
• GET /api/posts/9/comments/3 - 3 numaralı yorumu 9 numaralı gönderiye taşıyın.

Bir nesne üzerindeki eylem bir CRUD işlemi ise depolama kaynağı olarak kullanılabilir:

• POST /api/posts/9/like - benzerlik olarak 9 numaralı kayıt anlamına gelir;
• DELETE /api/posts/9/like - 9 numaralı gönderiden "nitelikli" simgesini kaldırın.

Kaynakların yaratılması ve yenilenmesi kaynağı tersine çevirebilir

POST, PUT veya PATCH yöntemleri, girilmeden önce dahil edilmemiş olan kaynak alanlarını (örneğin, kimlik, oluşturulma tarihi veya güncelleme tarihi) değiştirebilir. Kullanıcıyı API ile bunaltmamak için güncellenen verileri kaldırmak için başka bir istekte bulunmanız gerekir, bu tür yöntemler onları tersine çevirebilir.

Filtreleyin, sıralayın ve arayın

Sorguyu netleştirmek veya verileri sıralamak için wiki'lerde herhangi bir HTTP sorgu parametresi kullanılabilir.

• GET /api/users?state=active – aktif hesap kullanıcılarının listesi;
• GET /api/tasks?state=open&sort=priority,-created_at - önceliğe ve oluşturulma tarihine göre sıralanmış (yeni bir görevle başlayarak) oluşturulmamış görevlerin listesi.

Poster navigasyonu

Hedef listesine yan gezinme hakkında bilgi eklemeniz gerekiyorsa, veri sarmalayıcılar eklemek yerine hızlı bir şekilde HTTP Bağlantısı üstbilgisini kullanabilirsiniz.

Başlık Butonu:

Bağlantı: ; rel = "sonraki", ; rel = "önceki", ; rel = "ilk", ; rel = "son"

Olası rel değerleri:

• sonraki – sonuçlar sayfası geliyor;
• önceki – sonuçların ön tarafı;
• sonuçların ilk – ilk sayfası;
• son – sonuçların son tarafı.

Bazen yan gezinmenin basit bir sayfa araması yerine karmaşık kurallara dayanabilmesi için farklı URL'ler oluşturmak yerine bu anlamları anlamak önemlidir.

HTTP yöntemine yeniden atama

GET ve POST dışındaki HTTP yöntemlerini desteklemeyen bazı sunucu veya istemcilerle kullanım için bunların emülasyonu gerekli olabilir. Yöntemin değerleri X-HTTP-Method-Override başlığına aktarılır ve değerin kendisi POST yöntemi olarak etiketlenir. GET isteği sunucu kampını değiştirmek için suçlanamaz!

Kodi HTTP durumu

• 200 OK – başarılı bir isteğe yanıt GET, PUT, PATCH veya DELETE.
• 201 Oluşturuldu - POST yanıtı yeni bir nesnenin yaratılmasının sonucunu gösterecektir. Yanıta, kaynağın URL'sini belirten bir Konum başlığı da eşlik edebilir.
• 204 İçerik Yok – hiçbir şeyi değiştirmeyen bir komutun başarıyla tamamlandığını gösterir (örneğin, DELETE).
• 404 Bulunamadı - istenen nesne bulunamadı.
• 500 Dahili Sunucu Hatası – sunucuda hata.

Satın alma durumunda, tür mümkünse alıcılar için ek bilgi içerebilir.

Aktörler şöyle diyor:

"Tse API'si, wikirist'in HTTP isteği

AL, KOY, POSTі SİLMEK ".

Kim aynı şeyi söylediyse:

"Kaynak tahsisi için ek URI'ye bakın"

Diğerleri yüksek sesle bağırıyor:

Sonunda şunu söyleyebilirsiniz:

“Prensip olarak basit API'si, ne vikorist HTTP Sağ!"

Bu kişilerin eylemleri affı doğruladı,

Deyaki chastkovo verni,

ama hiçbir anlamı yok

Bo kokuyor herkes asıl noktayı kaçırıyor.

RESTful API geliştirmeyi mümkün kılmak için,

İlkine göre

REST nedir?

REST nedir?

REST:

Virazno HTTP değil

Chi protokol yok

Spesifikasyon yok

Neden bu kadar çok REST API var?

Ve henüz...

REST bir mimari tarzıdır.

Ah, vay be... bu mimari tarzı nedir?

Mimari tarzı

Bazhana mimarisi

Nihai mimariyi yaratan, yalnızca mimari ve mimariyi oluşturan bir dizi sınırdır.

Zastosovuyuchi ve ara bağlantılar, vikoristan'ın yer altı şelaleleri için optimize edilmiş fesleğen mimarisine dayanmaktadır.

REST, veri aktarımı anlamına gelir

Bu, Roy Fielding tarafından 2000 yılındaki doktora tezinde mevcut web mimarisini bir soyutlama olarak tanımlayarak kaydedildi.

Bula'nın adı, web takviyelerinin iyi gelişimiyle nasıl başa çıkılacağına dair Wikikati beyanına çağrılmaktadır.

Roy, REST'i basit bir örnekle anlattı:

Web sayfalarına sanal bir makine gibi bakalım.

Deri tarafı vücudu temsil eder:

1. İlk olarak koristuvach, ilk kampı indeks kampının görünümünden kaldırır.

2. Daha sonra koristuvach mesajı seçerek programı gözden geçirin (burada mesaj yan tarafa gönderilir)

3. Saldırının Koristuvachevi kampına aktarılmasının sonucu.

REST dosi HTTP değil

Elbette, 2000'li yılların başlarında ağ zaten HTTP üzerinde çalışıyordu ve Roy ile mühendis arkadaşları bunun üzerinde çok çalışıyorlardı.

Ancak REST, belirli sistem uygulama ayrıntılarını veya protokol sözdizimini belirtmez.

HTTP uyumlu protokollerin üzerine RESTful bir mimari oluşturmak tamamen mümkündür.

Örneğin, CoAP (İşbirlikçi Erişim Protokolü), cihazların (Nesnelerin İnterneti) dağıtımına yönelik bir RESTful protokolüdür ve hem cihazda hem de aynı anda minimum kaynak tahsis etmek için kullanılır.

Peki REST kullanmanın amacı nedir?

World Wide Web, REST mimarisini temel alır.

Bu nedenle, internette yaygın olan RESTful olmayan bir API oluşturursanız, optimumun altında bir sistem oluşturuyorsunuz demektir. Optimize edilmiş mimari için ideal değil.

RESTful olmayan bazı API'lerin uç mimari için ideal olmayabileceğini ancak diğer sorunlar için ideal olmayabileceğini unutmamak önemlidir. Örneğin, modern ön uç programlar çok özel ihtiyaçları karşılayabilir ve GraphQL veya Falcor gibi giderek artan sayıda veri toplama kütüphanesi vardır.

Peki kaç tane RESTful API var?

API, sürekli olarak REST sınırları altında çalışıyorsa RESTful'dur.

REST, istenen sistem optimizasyonuna ulaşmak için 6 sınır anlamına gelir:

1. İstemci-sunucu

Bu alışveriş çıkar ilkesine dayanmaktadır.

Bu, bileşenlerin bağımsız olarak gelişmesine olanak tanır. API'mizi oluşturduğumuzda çok sayıda istemciye hizmet veren bir sunucu görevi görür.

2. Toplu olmadan

İstemci ile sunucu arasındaki bağlantılar kesintisizdir. Bu, işlemi tamamlamak için gerekli tüm bilgilerle birlikte sunucuya girmenin müşterinin sorumluluğunda olduğu anlamına gelir.

Bu değişimin temel avantajı, sunucunun istekler arasında müşterinin zamanından tasarruf etmesine gerek kalmaması nedeniyle sistemin daha hızlı ölçeklenebilmesidir. İstemcinin sistemi hakkındaki bilgilerin hatırlanması ihtiyacı, sunucu kaynaklarını serbest bırakır, böylece aynı anda daha fazla istemciye hizmet verilebilir.

En etkili tedbir, tedbiri vikorize etmeyen tedbirdir.

API'mizi biz oluşturursak önbelleği görmezden gelmek bizim hatamız değil.

4. Doğru arayüz

Verimli önbelleklemeyi sağlamak için bileşenlerin tek bir arayüz üzerinden iletişim kurabilmesi gerekir. Tek bir arayüz ile istenilen bilgiler standart bir biçimde iletilebilmektedir.

4.1. Kaynakların tanımlanması

Bu, adlandırılabilecek herhangi bir bilginin bir kaynak (resim, belge veya bir dizi başka kaynak) olabileceği anlamına gelir.

4.2. Kaynakların tezahürler yoluyla manipülasyonu

Kaynak farklı şekillerde temsil edilebilir.

Örneğin HTML, XML, JSON veya JPEG dosyası gönderin.

Bu, müşterilerin kendi tezahürleri aracılığıyla kaynaklarla etkileşime girdiği anlamına gelir; bu da etkileşimlerindeki kaynakların soyut anlayışını büyük ölçüde azaltır.

4.3 Üçüncüsü, kişinin kendini tanımladığı bilgiler

Bu, kaynağın bildirilen isteğe açıklamalar sağlayabileceği ve sunucunun da site hakkında açıklamalar sağlayabileceği anlamına gelir. Bu nedenle, HTTP başlıkları ve yanıt kodları bu kuralın ana uygulamalarıdır.

4.4. Hypermedia bir motor ve bir program haline gelebilir

Bu aslında programın, istemcilerin hiper-güçlendirme yoluyla kaynaklara erişmesine olanak tanıyan güçlerle donatıldığı anlamına gelir.

Gördüğünüz gibi HTTP protokolünde pek çok kural uygulanabiliyor. Bu nedenle Vikorist API HTTP'yi doğru kullanıyorsa bu RESTful olmak için harika bir fırsattır.

5. Bagatory sistemi

Zengin bir ağ sisteminde, proxy sunucular gibi aracılar, tek modlu bir ağ arayüzü kullanılarak istemci ile sunucu arasına yerleştirilebilir.

Zengin sistemin avantajlarından biri, aracıların istemci-sunucu trafiğine şarkı amacıyla/örneğin önbelleğe alma amacıyla müdahale edebilmesidir.

6. Vimoga kodu

Bu karmaşık olmayan değişim, istemcilerin, istemci tarafında oturum açmak için programlar yüklemesine olanak tanır. Buna en iyi örnek JavaScript arayüz eklentileridir. Bu bizim için hemen aşikar olabilir, ancak İnternet'in ilk günlerinde gelişen bir kavram vardı ve bu, İnternet mimarisinin temel bir parçasıydı.

Peki REST API nasıl oluşturulur?

Düzgün bir şekilde vikoristuvat HTTP

Bir RESTful API istiyorsanız RESTful protokolünü vikorize edin. İnternet için HTTP protokolü ilk tercihtir. Doğru HTTP kullanımı için bir API oluşturun.

Tek bir arayüz oluşturun

Konseptlerinizi kaynaklarla uyumlu hale getirin ve her birine benzersiz tanımlayıcılar atayın. En basit yol, yabancılara yönelik bir veritabanı hizmeti kullanmak olacaktır. Böyle bir hizmet için iki kaynağı sayabiliriz; Koristuvachiv ve koristuvachiv (toplama kaynağı). Bu kaynaklar, API'nizin /users URI'si ve /user/(id) URI'si ile tanımlanabilir.

API'nin hiper güçlerini sergileyin

REST mimarisini hatırlayın

RESTful API oluşturmanın daha az zorlayıcı yönü, İnternet'i ve onun altında yatan mimariyi anlamanın ne kadar önemli olduğuyla ilgilidir. Bu optimizasyonu ya hızlandırabiliriz ya da görmezden gelebiliriz.

Yemek sorununuz varsa bizden rica ederiz.

Yazımı okuduğunuz için teşekkür ederim.
Yorumlar bölümünde tepkiler ve düşünceler her zaman ortalıkta dolaşıyor.

Merhaba sevgili okuyucular! Bu makaleyi okumaya başlamadan önce, beni yazmaya sevk eden bu yaratılışın ve vahyin hedeflerini anlatmak istiyorum.

Şirketimizin projelerinden biri olan Vinyl'de REST tarzında bir sunucu uygulaması tasarlama ihtiyacı ortaya çıktı. En başından beri basit bir görevle ne yapacağımızı ve bu amaçla en güçlü bilgiyi elde etmeyi merak ettik.

Mimariyi geliştirme ve REST hizmetlerini birleşik bir tarza getirme sürecine başladığımızda, meslektaşlarımız ve ben şu veya bu hususun uygulanması konusunda çelişkili sorunlar ve farklı bakış açıları yaşamaya başladık. Burada Google'ı açıp kolektif aklın yardımına gitmemiz, RESTful programları tasarlarken kaçınılması gereken en iyi uygulamaları öğrenmemiz gerektiğini anladık.

Bu makale, web eklentileriyle (ve muhtemelen REST hizmetleriyle) çalışma konusunda zaten net bir anlayışa sahip olan ancak bilgilerinin birleştirilmesi ve standartlaştırılmasını gerektirmeyen kişilerin ilgisini çekecektir.

Viznachennya

Başlamak için REST'in ne olduğunu bulmanız gerekir. Vikipedi bu beslenme cevabını veriyor. DİNLENMEK (Temsili Devlet Transferi- “Tezahüre aktarım”), bir sınır içindeki bölünmüş bir eklentinin bileşenleri arasındaki etkileşimin mimari tarzıdır. REST, dağıtılmış bir hipermedya sistemi tasarlanırken dikkate alınması gereken uygun bir bağlantı seti sağlar.

Kendi cümlelerimle REST kavramını “istemci ve sunucu uygulamaları arasındaki etkileşimi birleştirmenizi sağlayan bir dizi öneri” olarak açıkladım.
Bu yazımda REST hizmetlerini genel kabul görmüş uygulamalara uygun olarak tasarlamanıza ve oluşturmanıza yardımcı olacak bu “öneriler” hakkında sizleri bilgilendirmeye çalışacağım.

Ayrıca bunun bir REST hizmeti olduğunu da anlayın. REST hizmetini “istemci programı ile sunucu arasındaki etkileşim noktası” olarak tanımladım. Java terminolojisinde bu, istemcinin isteği gönderdiği bir sunucu uygulamasıdır.

Sorunlar

Kuralları açıklamaya başlamadan önce, REST'in bir standart olmadığı fikrini aktarmak isterim çünkü uyulması gereken tek tip kurallar yoktur. Bu, şu veya bu durumu en iyi şekilde çözebilecek çözümlerin hâlâ daha iyi anlaşılmasının mümkün olmadığı anlamına geliyor. Her özel durumda hangi HTTP yöntemlerinin kullanılacağını ve hangi HTTP kodunun kullanılacağını okumak çok yaygındır.

Hizmet adı

Başlamak için REST hizmeti için bir ad seçmeniz gerekir. Hizmet adı altında isteğin URI'sindeki yolunuza saygı duyuyorum. Örneğin, http://my-site.by/api/rest/service/name. Bir isim seçmek için REST mimarisinde “kaynakların” ne olduğunu anlamamız gerekiyor.

Kaynağa gönderim

REST terminolojisinde bu bir kaynak olabilir (bir HTML belgesi, resimler, belirli bir istemciyle ilgili bilgiler vb.). Kaynak gerçek bir nesne olduğundan, XML veya JSON gibi standart bir biçimde görülmesi kolaydır. Daha sonra sunucu bu kaynağı seçilen formatı kullanarak gönderebilir ve istemci, sunucudan seçilen kaynakla çalışabilir.

JSON formatında "profil" kaynağına gönderilen örnek:

"kimlik" :1 ,

"isim" :"Mahesh",

"giriş" :"manesh"

REST, kaynakları temsil etmek için kullanılacak formata herhangi bir açık kısıtlama getirmez ve kaynakları temsil etmek için kullanılacak bir format geliştirirken takip edilmesi gereken birkaç kural vardır:

• Seçilen formatın anlaşılmasından ve çalışılabilmesinden istemci ve sunucu sorumludur.
• Kaynak, karmaşıklığına bakılmaksızın seçilen herhangi bir formatta tamamen tanımlanabilir.
• Format, kaynaklar arasında bağlantı kurma olasılığını aktarabilir.

Kaynak "isteğine" gönderim ve kaynak "profili" ile bağlantı örneği:

kimlik: 11254,

para birimi: "EUR",

miktar: 100

profil: (

kimlik: 11,

ur: "http://MyService/Profiles/11"

Gördüğünüz gibi başka bir kaynağa atanmış bir kaynağın tüm yapısının kopyalanması zorunlu değildir. Natomist vikoristovvat'ı daha akıllıca başka bir kaynağa gönderebilir.

Zvernennya'dan kaynağa

Cilt kaynağı, kalıcı bir tanımlayıcıyla benzersiz bir şekilde tanımlanabilir. "Kalıcı", tanımlayıcının veri alışverişi saati boyunca değişmediği, değiştiğinde kaynağa atanacağı anlamına gelir. Kaynağa farklı bir tanımlayıcı atanırsa, sunucunun istemciye bildirimde bulunması gerekir; bu, daha sonra yeni adrese gönderim tarihini gösterecektir. Bir kaynak, bir URL ile benzersiz bir şekilde tanımlanır. Bu, URL'nin veri öğesi için birincil anahtar olduğu anlamına gelir. Örneğin Totto, polis matima'nın baktığı kitaptan başka bir kitap /kitaplar/2 ve bu kitabın 41. yüzü /kitaplar/2/sayfalar/41 . Zvіdsi ve görev biçiminden çıkın. Üstelik adresin arkasındaki verinin hangi formatta olduğu hiç önemli değil /kitaplar/2/sayfalar/41 – Bu HTML, jpeg dosyasının taranmış kopyası veya Word belgesi olabilir.

Bir REST hizmetine ad atarken birden çok kaynak adının seçilmesi önerilir. Bu yaklaşım, mevcut hizmetlerin adlarını genişletmeden yeni REST hizmetleri eklemenizi sağlar. Örneğin, hizmet /kitabın bize tüm kitaplarınızın bir listesini verin, /kitaplar/3 3. kitap ve hizmetle ilgili bilgilere bakın /kitaplar/3/sayfalar üçüncü kitabın tüm taraflarını çevirin.

Bir kaynak üzerinde belirli eylemler oluşturan hizmetler için eylemlerin girilmesine yönelik iki yaklaşım vardır: hizmet adında veya parametrelerinde. Örneğin, /books/3/clean veya /books/3?clean . İlk seçeneği tercih ediyorum, çünkü bu tür hizmetler genellikle parametrelerin URL'ye aktarılmasını desteklemeyen POST yöntemlerini kullanır, bu da hizmeti bence pek okunabilir kılmaz. Hizmet adındaki eylemin türüne bağlı olarak, HTTP yönteminin türüne bağlı olarak hizmetimizi mümkün olduğunca daha da genişleteceğiz.

Ayrıca solda etiketi bulunan ve depo hizmetinin işini anlatan isimlerin kullanılması da önerilmez (Java yöntemleri isimlendirilirken çalışılması önerildiği için). Örneğin, zamist /getAllCars para kazanmanın daha iyi bir yolu /arabalar . Yöntem tek kelimeyle anlatılamayacağı için tek tip ayırıcılar oluşturmak gerekiyor, ben vikory '-' diyorum ki bu en popüler yaklaşımdır. Örneğin, /arabalar/3/can-satılabilir.

REST hizmet adlarının tasarımı hakkında daha fazla ayrıntı şurada okunabilir:

HTTP yöntemi

REST'in 4 ana HTTP yöntemi vardır: GET, POST, PUT, DELETE. Çoğu zaman, yöntemlerin dış görünümü CRUD ile işin sonuna kadar hizmet edecektir ( C anla, R ead, sen tarih, D elete – “oluşturma, okuma, güncelleme, görüntüleme”).
POST – oluştur, GET – oku, PUT – güncelle, DELETE – sil.

ÖNEMLİ EKLEME: Bunlara, uygulanması gereken HTTP yöntemleriyle ilgili olan REST Kalıpları adı verilir. Eve daha yakın olan farklı modeller, POST ve PUT'a farklı şekillerde bakar. Ancak oluşturma, değiştirme veya güncellemeye ilişkin PUT atamaları POST için atanmaz. Bu nedenle POST ve PUT kodları değiştirilebilir. Çoğu durumda, POST oluşturma için, PUT ise düzenleme için kullanılır; nedenini biraz sonra açıklayacağım.

Kaynaklarla etkileşimin çeşitli yöntemlerine ilişkin birkaç örnek sunacağım.

• GET /kitaplar/- Tüm kitapların listesini seçer. Bağışlanmayı çağır, hepsi bu. Başka veriler olmadan yalnızca tanımlayıcı ve nesne adı alanlarını yerleştirin.
• GET /kitaplar/(id)- Kitapla ilgili daha fazla bilginin kaldırılması.
• POST /kitaplar/- Yeni bir kitap hazırlıyorum. Veriler bir notta iletilir.
  PUT /kitaplar/(kimlik)– kitap hakkındaki verileri tanımlayıcı (id) ile değiştirir, muhtemelen bunların yerine geçer. Talep üzerine veriler de iletilir.
• SEÇENEKLER /kitaplar- Atanan kaynak için desteklenen işlemlerin listesini seçer (pratikte vikorize edilmez)
• SİL /kitaplar/(kimlik)– tanımlayıcıdan (id) verileri siler.

Güvenlik ve bağımsızlık

Ayrıca bu yöntemlerin güvenliğini ve önemsizliğini bilmek bir HTTP yöntemi seçmenize de yardımcı olacaktır.

Dikkatsizce yapılan bir istek, programın durumunu değiştirmeyen bir istek değildir.

Eş-güçlü bir istek, etkisi çok yanıtlı bir türetmenin tek kullanımlık bir türetmenin etkisinden daha eski olduğu bir istek değildir.

Bu tabloya bakılırsa GET isteği, durgunlaşan kaynağın durumunu değiştirmez. PUT ve DELETE ifadeleri kaynağın durumunu değiştirebilir, ancak önceki ifadenin sona ermesine dair bir neden olmadığından sakin bir şekilde tekrarlanabilirler. Prensip olarak mantıklıdır: Belirli bir kaynağı tekrar tekrar tekrarlarsanız ve onu belirli bir kaynakla değiştirirseniz, sonuç, kaynağın daha da değiştirilmesi olacaktır. Ale POST, tabloda görüldüğü gibi güvenli ve önemsiz olarak yazılmıştır. Yalnızca kaynağı değiştirmekle kalmaz, aynı zamanda sıklıkla tekrarlanan etki de oldukça değişkendir. Bu, bunun yerine yeni DB öğeleri ekleme işlemiyle temsil edilir: pencere X kez yazılır ve DB, X öğeleri alır.

Ayrıca kaynağın durumunu değiştirmekten GET isteklerinin neden sorumlu olmadığını da belirteceğim. GET istekleri, örneğin bir proxy sunucusunda önbelleğe alınabilir. Bu durumda istek sunucuya program tarafından ulaşmayabilir, ancak proxy sunucu bilgileri önbellekten döndürdüğü için ulaşabilir.

HTTP kodu

HTTP standardı 70'in üzerinde durum kodunu açıklar. İyi formda, ana olanları isterim.

• 200 – Tamam – başarılı istek. İstemci herhangi bir veri talep etmişse, bu başlıkta ve/veya bilgilerde görünecektir.
• 201 – Tamam – başarılı bir arayış sonucunda yeni bir kaynak oluşturuldu.
• 204 – Tamam – kaynak başarıyla alındı.
• 304 – Değiştirilmedi – istemci önbellekten verilere erişebilir.
• 400 – Hatalı İstek – istek geçersiz veya istek işlenemiyor.
• 401 – Yetkisiz – istek müşterinin kimlik doğrulamasını gösterir.
• 403 – Yasak – sunucu izin istedi ancak bunu işlemesine izin verilmiyor ve erişim engelleniyor.
• 404 – Bulunamadı – kaynak bulunamadı.
• 500 – Dahili Sunucu Hatası – API geliştiricileri bu tür hatalardan kaçınmaktan suçludur.

Bu faydalar küresel yakalama bloğundan elde edilebilir, taahhüt edilebilir veya başka bir şekilde şubeden geri çevrilebilir.

Vikorize edeceğimiz kod kümesi ne kadar büyük olursa, oluşturduğumuz API de o kadar akıllı olacaktır. Ancak tarayıcıların bu kodları farklı şekilde işlediğini unutmayın. Örneğin 307 yanıt kodunu reddeden bazı tarayıcılar anında yönlendirme görüntülüyor, bazıları ise bu durumu ele alıp eylemi kaydetmenize olanak tanıyor. Her şeyden önce istemci tarafında nasıl çalıştığını anlamak önemlidir!

Başlıklar

• İçerik türü- İstenen format;
• Kabul etmek- Yayın formatlarının listesi.

Kaynak arama parametreleri

Herhangi bir bilginin işlenmesinden sorumlu olan hizmetlerin seçimini basitleştirmek ve aynı zamanda bunları daha verimli hale getirmek için, alan ormanı ve sayfalandırmayı sıralama, filtreleme vb. İçin parametrelerin nasıl girileceğini anlamak gerekir.

Filtrasyon

Filtreleme için cilt alanı için benzersiz bir parametre oluşturun. Bu, çıktı olarak verilen bilgi miktarını sınırlamanıza olanak tanır ve bu da isteğin işlem süresini optimize eder.

Örneğin, tüm kırmızı kitapları görüntülemek için şunu yazmanız gerekir:

GET /kitaplar?renk=kırmızı

Sortuvannya

Sıralama, filtrelemeye benzer şekilde uygulanır. Örneğin, tüm kitapları yayınlanma tarihine ve başlığa göre büyüme sırasına göre sıralanmış olarak görüntülemek için aşağıdaki girişi girmeniz gerekir:

GET /books?sort=-yıl,+ad

Sayfalandırma

REST API, programın aynı sayfasında görünebilecek kaynakların bir listesine erişme olasılığını desteklemek için sayfalandırma işlevini kullanır. Bizim tarafımızdan bilinen SQL parametreleri kullanılarak uygulanır: limit ve ofset. Örneğin:

GET /books?offset=10&limit=5

Ayrıca Bağlantı başlığının ön, arka, ilk ve kalan sayfalarında bir mesaj görüntülemek iyi bir yöntemdir. Örneğin:

Bağlantı: ; rel = "sonraki",
; rel = "son",
; rel = "ilk",
; rel = "önceki"

Kaynak için alanları seçin

Manuel bir hizmet için trafikten tasarruf etmek amacıyla veri görüntüleme formatını özelleştirme olanağı ekleyebilirsiniz. Kaynak için REST hizmetini güncelleyebilecek alanları seçmek mümkündür. Örneğin, hem kitap kimliklerini hem de renklerini kaldırmanız gerekiyorsa sonraki girişi girmeniz gerekir:

GET /kitaplar?fields=kimlik,renk

Seni kurtaracağım

RESTful hizmetlerinin değişiminin nedenlerinden biri, istekleri kaldırmak için müşterinin zamanından tasarruf etmek zorunda olmalarıdır.

Para tasarrufu sağlamayan hizmete bir örnek:
İstek1:
İstek2: http://MyService/Persons/2 HTTP/1.1'İ ALIN

Bu içeceklerden her ne olursa olsun ciltte cilt problemleri gelişebilir.

Para tasarrufu sağlayan bir hizmet örneği:
İstek1: http://MyService/Persons/1 HTTP/1.1'İ ALIN
İstek2: http://MyService/NextPerson HTTP/1.1'İ ALIN

Başka bir isteği işlemek için sunucunun, istemcinin talep ettiği kalan kişinin kimliğini "hatırlaması" gerekir. Tobto. Sunucu, üretim hattını “hafızaya almaktan” sorumludur, aksi takdirde başka bir tedarik sorun yaratabilir. Bir hizmeti tasarlarken, önceliği düşük bırakarak enerji tasarrufu yapmaya gerek yoktur.

Maliyetten tasarruf etmeyen hizmetin avantajları:

• servis birbirinden bağımsız olarak içecek ister;
• hizmetin mimarisi veda edecek;
• Verileri kaydetmeyen HTTP protokolünü kullanarak hizmetleri uygulamak için ek bir çabaya gerek yoktur.

Para tasarrufu sağlamayan yeterli hizmet yok:

• Bağlamın gerektirdiği hizmetin hizmete aktarılmasından müşterinin kendisi sorumludur.

Sürüm

REST API sürümünün desteklenmesi iyi bir uygulamadır. Bu, halihazırda onu kullanan istemcileri değişiklik yapmaya zorlamadan API'yi kolayca genişletmenize olanak tanır.
Sürüm oluşturmanın uygulanmasına yönelik bir dizi yaklaşım:

• Daha fazla yardım için başlığı kabul edin. Bu durumda API sürümü Kabul et'te belirtilir - Kabul et:text/v2+json
• Z wikiristannyam URI'si. Bu yaklaşımda API sürümü doğrudan URI'de belirtilir - http://localhost/api/v2/books
• Özel başlık wiki'si. API sürümünün iletilmesinden de sorumlu olan güç başlığını kullanabilirsiniz. - API Sürümü:v2
• Vikoristannya parametresi sorulur. API sürümü aktarım parametresini kullanabilirsiniz - /kitaplar?v=2

Sunulan yöntemlerin her birinin uyku hakkı vardır, her birinin kendi artıları ve eksileri vardır. Ancak hangi sürüm kontrolünü uygulama yönteminin projenize uygun olacağına karar vermek size kalmıştır.

Dokümantasyon

REST hizmetlerimizi manuel olarak yapılandırmak için iyi ve kapsamlı belgeler oluşturmanız gerekir. Bunun için Mashape veya Apiary gibi farklı araçlar kullanabilirsiniz ama ben Swagger kullanmanızı tavsiye ederim.

Swagger, REST hizmetlerini belgelemenizi sağlayan bir teknolojidir. Swagger, kimliği belirsiz programlamayı ve çerçeveleri teşvik eder. Plus Swagger, belgeleri incelemek için bir kullanıcı arayüzü sağlar.

Swagger'a ait rapor bilgilerini ücretli olarak görüntüleyebilirsiniz.

Arşiv

Keshuvannya

Ayrıca veritabanına gelen istekleri hızlandırmak ve REST hizmetlerimiz için veri hızını artırmak için önbellekleme mekanizmasının ayarlanması önerilir. Önbelleğe alma hem sunucu düzeyinde hem de duruma bağlı olarak ayarlanabilir.

Keshuvannyam aşağıdaki HTTP başlıklarını kullanabilir:

• Tarih - kaynağın oluşturulduğu tarih ve saat.
• Son Değiştirilme – sunucudaki kaynakta yapılan son değişikliğin tarihi ve saati.
• Önbellek Kontrolü, önbellekleri kontrol etmek için kullanılan bir HTTP 1.1 başlığıdır.
• Yaş - kaynağın kalan yakalanma anından sonraki saat, başlık, ara (istemci ile sunucu arasında) bileşen (örneğin, bir proxy sunucusu) tarafından eklenebilir