HTTP ve REST arasındaki fark nedir?

REST ve SOAP arasındaki farklar hakkında çok şey okuduktan sonra, REST'in HTTP için başka bir kelime olduğu izlenimini edindim. Birisi REST'in HTTP'ye hangi işlevleri eklediğini açıklayabilir mi?

Not : REST ile SOAP karşılaştırması aramıyorum.

Güncelleme : Cevaplarınız için teşekkürler. Şimdi REST'in HTTP'nin nasıl kullanılacağına dair bir dizi kural olduğu açıktı. Bu nedenle bu sözleşmelerin avantajlarının ne olduğu konusunda bir takip yaptım .

Not : Şimdi REST'in anlamını kavradım; Emil Ivanov'un belirttiği gibi REST, HTTP'yi olması gerektiği gibi kullanmak anlamına gelir. Ancak, bunun kendi başına bir terimi hak edip etmediğinden emin değilim ve kesinlikle hype'ı anlamıyorum.

Hayır, REST , HTTP'nin kullanılması gereken yoldur .

Bugün yalnızca HTTP protokol yöntemlerden bir nebze kullanmak - yani GETve POST. Bunu yapmanın REST yolu, protokolün tüm yöntemlerini kullanmaktır.

Örneğin, REST DELETE, bir URI'nin arkasındaki bir belgeyi (dosya, durum vb.) Silmek için kullanımını belirtirken, HTTP ile bir GETveya POSTsorguyu kötüye kullanırsınız ...product/?delete_id=22.

HTTP, iletişim için kullanılan, genellikle internet kaynakları veya bir web tarayıcı istemcisi olan herhangi bir uygulama ile iletişim kurmak için kullanılan bir protokoldür.

REST, uygulamayı tasarlarken kullandığınız ana kavramın Kaynak olduğu anlamına gelir: gerçekleştirmek istediğiniz her eylem için genellikle sadece CRUD işlemini yaptığınız bir kaynak tanımlamanız gerekir, bu basit bir görevdir. bunun için 4 CRUD işlemine karşı HTTP protokolünde kullanılan 4 fiili kullanmak çok uygun (Okuma için Al, POST CREATE, PUT UPDATE ve DELETE DELETE içindir). kullanıcının çağrısı sonucunda gerçekleştirmek istediğiniz bir dizi eyleminizin olduğu eski RPC (Uzaktan Yordam Çağrısı) konseptinden farklıdır. örneğin bir gönderide olduğu gibi bir facebook'u nasıl tanımlayacağınızı düşünüyorsanız, RPC ile AddLikeToPost ve RemoveLikeFromPost adlı hizmetler oluşturabilir ve FB gönderileriyle ilgili diğer tüm hizmetlerinizle birlikte yönetebilirsiniz, böylece özel oluşturmanız gerekmez nesnesi gibi. REST ile Sil ve Oluştur işlevleriyle ayrı ayrı yönetilecek bir Like nesneniz olacaktır. Ayrıca, db'nizde ayrı bir varlık tanımlayacağı anlamına gelir. bu küçük bir fark gibi görünebilir, ancak bu şekilde çalışmak genellikle çok daha basit bir kod ve çok daha basit bir uygulama sağlar. bu tasarımla, uygulamanın mantığının çoğu, genellikle çok daha fazla mantık eklemek zorunda kalacağınız RPC'nin aksine, nesnenin yapısından (model) açıktır.

RESTful uygulaması tasarlamak genellikle çok daha zordur çünkü karmaşık şeyleri basit bir şekilde tanımlamanızı gerektirir. sadece CRUD işlevlerini kullanarak tüm işlevleri tanımlamak zordur, ancak bunu yaptıktan sonra hayatınız çok daha basit olacaktır ve çok daha kısa yöntemler yazacağınızı göreceksiniz.

Mevcut diğer bir kısıtlama REST mimarisi, istemciyle (vatansız) iletişim kurarken oturum bağlamını kullanmamaktır, yani tüm bilgilerin istemcinin kim olduğunu ve ne istediğini web mesajıyla iletildiğini anlaması gerekir. bir işleve yapılan her çağrı kendinden açıklayıcıdır, istemciyle mesajda referans verilebilecek daha önceki bir konuşma yoktur. bu nedenle bir müşteri size "bir sonraki sayfayı ver" diyemedi çünkü önceki sayfanın ne olduğunu ve ne tür bir sayfa istediğinizi saklamak için bir oturumunuz olmadığı için, müşteri "benim adım yuval, get msgstr "Belirli bir forumdaki belirli bir gönderinin sayfa 2'sini görüntüle". Bu, iletişimde biraz daha fazla veri aktarılması gerektiği anlamına gelir, ancak "beni bir sonraki sayfaya getir" işlevinden bildirilen bir hata bulma arasındaki farkı düşünün.

Tabii ki çok daha fazlası var, ama bence bir çay kaşığı içindeki ana kavramlar.

HTTP bir uygulama protokolüdür. REST, izlendiğinde, belirli bir dizi istenen kısıtlamaya sahip dağıtılmış bir uygulama oluşturmanıza olanak tanıyan bir dizi kuraldır.

RESTful uygulamasını herhangi bir HTTP uygulamasından ayıran en önemli REST kısıtlamalarını arıyorsanız, "kendini tanımlama" kısıtlaması ve hiper ortam kısıtlaması (Uygulama Durumunun Motoru olarak Hypermedia (HATEOAS)) en önemli.

Kendini açıklama kısıtlaması, kullanıcıların niyetinde tamamen kendini tanımlayıcı olmak için RESTful isteğinin olmasını gerektirir. Bu, aracıların (proxy'ler ve önbellekler) mesaj üzerinde güvenli bir şekilde hareket etmesini sağlar.

HATEOAS kısıtlaması, uygulamanızı istemcinin mevcut durumunun o web'deki yerine dayandığı bir bağlantı ağına dönüştürmektir. Zor bir kavram ve açıklamak için şu an sahip olduğumdan daha fazla zaman gerekiyor.

Anladığım kadarıyla REST, kullanılabilir HTTP komutlarının kullanılması gerektiği gibi kullanılmasını zorunlu kılar.

Örneğin, yapabilirim:

GET
http://example.com?method=delete&item=xxx

Ancak dinlenme ile "DELETE" istek yöntemini kullanır, "yöntem" sorgu parametresi gereksinimini ortadan kaldırır

DELETE
http://example.com?item=xxx

Pek değil ...

http://en.wikipedia.org/wiki/Representational_State_Transfer

REST başlangıçta HTTP bağlamında tanımlanmıştır, ancak bu protokolle sınırlı değildir. RESTful mimarileri, anlamlı temsili durumun transferine dayanan uygulamalar için zaten zengin ve tekdüze bir kelime dağarcığı sağlıyorsa diğer Uygulama Katmanı protokollerine dayanabilir. RESTful uygulamaları, önceden belirlenmiş, iyi tanımlanmış arabirimin ve seçilen ağ protokolü tarafından sağlanan diğer yerleşik özelliklerin kullanımını en üst düzeye çıkarır ve üstüne yeni uygulamaya özgü özelliklerin eklenmesini en aza indirir.

http://www.looselycoupled.com/glossary/SOAP

(Basit Nesne Erişim Protokolü) Web hizmetleri mesajları için standart. XML tabanlı SOAP, bir zarf biçimi ve içeriğini tanımlamak için çeşitli kurallar tanımlar. Web hizmetlerinin üç temel standardından biri olarak (WSDL ve UDDI ile birlikte), web hizmetlerinin değişimi için tercih edilen protokoldür, ancak hiçbir şekilde tek; REST taraftarları gereksiz karmaşıklık kattığını söylüyor.

REST, büyük sistemlerin (web gibi) tasarımına yaklaşmanın özel bir yoludur.

Bu bir 'kurallar' (veya 'kısıtlamalar') kümesidir.

HTTP, bu kurallara uymaya çalışan bir protokoldür.

REST = Temsili Durum Transferi

REST , izlendiğinde, belirli bir dizi istenen kısıtlamaya sahip dağıtılmış bir uygulama oluşturmanıza olanak tanıyan bir dizi kuraldır.

REST , bu iletileri taşımak için HTTP kullanabilen (XML, JSON vb.) İletileri alıp vermek için kullanılan bir protokoldür.

Özellikleri:

Vatansızdır, yani istemci ile sunucu arasında ideal bir bağlantı kurulmamalıdır. Bağlamını sunucuya iletmek istemcinin sorumluluğundadır ve daha sonra sunucu, istemcinin ek isteğini işlemek için bu bağlamı saklayabilir. Örneğin, sunucu tarafından tutulan oturum, istemci tarafından geçirilen oturum tanımlayıcısı ile tanımlanır.

Vatansızlığın Avantajları:

1. Web Hizmetleri her yöntem çağrısını ayrı ayrı ele alabilir.
2. Web Hizmetleri, istemcinin önceki etkileşimini korumasına gerek yoktur.
3. Bu da uygulama tasarımını basitleştirir.
4. HTTP, TCP'nin aksine durumsuz bir protokoldür ve bu nedenle RESTful Web Services, HTTP protokolleriyle sorunsuz bir şekilde çalışır.

Vatansızlığın Dezavantajları:

1. Müşterinin durumunu korumak için her talebe başlık şeklinde bir ekstra katman eklenmesi gerekir.
2. Güvenlik için her isteğe bir başlık bilgisi eklememiz gerekir.

REST tarafından desteklenen HTTP Yöntemleri:

GET: / string / someotherstring Bu idempotenttir ve her arama yapıldığında ideal olarak aynı sonuçları döndürmelidir

PUT: GET ile aynı. Idempotent ve kaynakları güncellemek için kullanılır.

POST: bir url ve gövde içermelidir Kaynak oluşturmak için kullanılır. Birden fazla çağrı ideal olarak farklı sonuçlar döndürmeli ve birden fazla ürün oluşturmalıdır.

SİL: Sunucudaki kaynakları silmek için kullanılır.

BAŞ:

HEAD yöntemi, GET ile aynıdır, ancak sunucu yanıtta bir ileti gövdesi döndürmemelidir. Bir HEAD isteğine yanıt olarak HTTP başlıklarında yer alan meta bilgiler, bir GET isteğine yanıt olarak gönderilen bilgilerle aynı OLMALIDIR.

SEÇENEKLER:

Bu yöntem, istemcinin bir kaynak eylemini ima etmeden veya bir kaynak geri alma işlemini başlatmadan bir kaynakla veya bir sunucunun yetenekleriyle ilişkili seçenekleri ve / veya gereksinimleri belirlemesine olanak tanır.

HTTP Yanıtları

Tüm yanıtlar için buraya gidin .

Burada birkaç önemli nokta bulunmaktadır: 200 - OK 3XX - İstemciden gereken ek bilgiler ve url yönlendirmesi 400 - Hatalı istek
401 - 403'e erişim
yetkisi yok - Yasak
İstek geçerli, ancak sunucu işlemi reddediyor. Kullanıcı bir kaynak için gerekli izinlere sahip olmayabilir veya bir çeşit hesaba ihtiyaç duyabilir.

404 - Bulunamadı
İstenen kaynak bulunamadı, ancak gelecekte kullanılabilir. Müşteri tarafından müteakip isteklere izin verilir.

405 - Yönteme İzin Verilmiyor İstenen kaynak için bir istek yöntemi desteklenmiyor; örneğin, verilerin POST yoluyla sunulmasını gerektiren bir formdaki GET isteği veya salt okunur bir kaynakta PUT isteği.

404 - İstek bulunamadı
500 - Dahili Sunucu Hatası
502 - Hatalı Ağ Geçidi Hatası

HTTP, mesajları bir ağ üzerinden ileten bir iletişim protokolüdür. SOAP, bu mesajları taşımak için HTTP kullanabilen XML tabanlı mesaj alışverişi yapan bir protokoldür. Dinlenme, bu iletileri taşımak için HTTP kullanabilen (XML veya JSON) iletileri alıp vermek için kullanılan bir protokoldür.

HTTP is a contract, a communication protocol and REST is a concept, an architectural style HTTP, FTP veya diğer iletişim protokollerini kullanabilir ancak HTTP ile yaygın olarak kullanılır.

REST implies a series of constraints about how Server and Client should interact. HTTP is a communication protocol with a given mechanism for server-client data transfer, REST API'de en çok REST was inspired by WWW (world wide web) which largely used HTTPREST tanımlanmadan önce kullanıldığından, REST API stilini HTTP ile uygulamak daha kolaydır.

There are three major constraints in REST (but there are more):

1. Sunucu ve istemci arasındaki etkileşim yalnızca köprü metni aracılığıyla açıklanmalıdır.

2.Sunucu ve istemci gevşek bir şekilde bağlanmalı ve birbirleriyle ilgili varsayımda bulunmamalıdır. İstemci yalnızca kaynak giriş noktasını bilmelidir. Etkileşim verileri yanıtta sunucu tarafından sağlanmalıdır.

3.Sunucu, istek bağlamıyla ilgili hiçbir bilgi depolamamalıdır. İstekler bağımsız ve idempotent olmalıdır (aynı istek sonsuz bir şekilde tekrarlanıyorsa, tam olarak aynı sonuç alınır)

Ve HTTP sadece bunu başarmaya yardımcı olabilecek bir iletişim protokolüdür (bir araç).

Daha fazla bilgi için şu bağlantıları kontrol edin:

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

DİNLENME ille bağlı değildir HTTP . RESTful web hizmetleri sadece RESTful mimarisini takip eden web servisleridir.

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

Gönderen HTTP ve REST arasındaki farkı bilmiyorsunuz

Bu nedenle REST mimarisi ve HTTP 1.1 protokolü birbirinden bağımsızdır, ancak HTTP 1.1 protokolü REST ilkelerini ve kısıtlamalarını takip etmek için ideal protokol olacak şekilde oluşturulmuştur. HTTP ve REST arasındaki ilişkiye bakmanın bir yolu, REST'in tasarım ve HTTP 1.1 ise bu tasarımın bir uygulamasıdır.

REST API'leri köprü metne dayalı olmalıdır

Gönderen Roy Fielding'in blogunda burada bir HTTP API veya REST API bina kontrol edeceğiniz yollar bir dizi var:

API tasarımcıları, oluşturma işleminize REST API'sini çağırmadan önce lütfen aşağıdaki kurallara dikkat edin:

• Bir REST API herhangi bir iletişim protokolüne bağlı olmamalıdır, ancak belirli bir protokole başarılı bir şekilde eşleştirilmesi meta verilerin kullanılabilirliğine, yöntem seçimine vb. Bağlı olabilir. Genel olarak, tanımlama için bir URI kullanan herhangi bir protokol öğesinin izin vermesi gerekir. bu tanımlama amacıyla kullanılacak herhangi bir URI şeması. [Buradaki başarısızlık, kimliğin etkileşimden ayrı olmadığını ima eder.]
• Bir REST API'si, HTTP'nin PATCH yöntemi veya Bağlantı başlığı alanı gibi standart protokollerin eksik belirtilmiş bitlerinin doldurulması veya düzeltilmesi dışında iletişim protokollerinde herhangi bir değişiklik içermemelidir. Bozuk uygulamalar için (HTML'nin HTTP'nin yöntem kümesini tanımladığına inanacak kadar aptal tarayıcılar gibi) geçici çözümler ayrı olarak veya en azından eklerde, geçici çözümün sonunda eski olacağı beklentisiyle tanımlanmalıdır. [Buradaki başarısızlık, kaynak arabirimlerinin genel değil nesneye özgü olduğunu gösterir.]
• Bir REST API, neredeyse tüm açıklayıcı çabalarını kaynakları temsil etmek ve uygulama durumunu göstermek için kullanılan medya türlerini tanımlamak veya mevcut standart medya türleri için genişletilmiş ilişki adları ve / veya hipermetin özellikli işaretleme tanımlamak için harcamalıdır. Hangi URI'lerde hangi yöntemlerin kullanılacağını tanımlamak için harcanan her türlü çaba, bir medya türü için (ve çoğu durumda zaten mevcut medya türleri tarafından tanımlanmış) işleme kuralları kapsamında tanımlanmalıdır. [Buradaki başarısızlık, bant dışı bilginin köprü metni yerine etkileşimi tetiklediğini gösterir.]
• Bir REST API'sı sabit kaynak adları veya hiyerarşileri tanımlamamalıdır (istemci ve sunucunun bariz bir şekilde birleştirilmesi). Sunucular kendi ad alanlarını kontrol etme özgürlüğüne sahip olmalıdır. Bunun yerine, sunuculara, ortam türleri ve bağlantı ilişkileri içindeki bu yönergeleri tanımlayarak, istemcilere HTML formlarında ve URI şablonlarında yapılan gibi uygun URI'lerin nasıl oluşturulacağı konusunda talimat verme izni verin. [Buradaki başarısızlık, istemcilerin, RPC'nin işlevsel kuplajına veri odaklı eşdeğeri olan etki alanına özgü bir standart gibi bant dışı bilgiler nedeniyle bir kaynak yapısı üstlendiğini ima eder].
• Bir REST API hiçbir zaman istemci için önemli olan “türetilmiş” kaynaklara sahip olmamalıdır. Spesifikasyon yazarları, arayüzün arkasında sunucu uygulamasını tanımlamak için kaynak türlerini kullanabilir, ancak bu türlerin alakasız ve istemci için görünmez olması gerekir. Bir istemci için önemli olan türler yalnızca geçerli sunumun ortam türü ve standartlaştırılmış ilişki adlarıdır. [Aynen]
• İlk URI (yer imi) ve hedeflenen kitleye uygun (yani API'yı kullanabilecek herhangi bir müşteri tarafından anlaşılması beklenen) standartlaştırılmış ortam türleri kümesi dışında önceden bilgi olmadan bir REST API girilmelidir. Bu noktadan sonra, tüm uygulama durumu geçişleri, alınan sunumlarda bulunan veya kullanıcının bu sunumları manipüle etmesiyle ima edilen, sunucu tarafından sağlanan seçeneklerin istemci seçimiyle yönlendirilmelidir. Geçişler, müşterinin medya türleri ve kaynak iletişim mekanizmaları hakkındaki bilgileri, her ikisi de anında (ör. İsteğe bağlı kod) geliştirilebilecek şekilde belirlenebilir (veya sınırlandırılabilir). [Buradaki başarısızlık, bant dışı bilginin köprü metni yerine etkileşimi tetiklediğini gösterir.]