REST web için ve web REST için tasarlanmıştır. İki uygun olan birlikte olacak. Roy Fielding'in 2000 Doktora Tezi Mimari Stilleri ve Ağ Tabanlı Yazılım Mimarilerinin Tasarımı REST terimini tanımladı ve tanıttı ve web ile REST arasında önemli bir etkileşim var: Roy Fielding, birincil yazarı olduğu HTTP / 1.1 üzerinde çalıştı, ve orada öğrendiklerini tezinde REST'i tanımlamak için kullandı.
Bu nedenle, web ve REST'in birlikte bu kadar iyi gitmesinin basit nedeni, REST'in tanımının web'in nasıl çalıştığından çıkarılması ve web'in REST'in bir uygulaması olmasıdır.
Bu nedenle REST, web hizmetleri ve web uygulamaları için iyi bir seçimdir: çünkü zaten "insan" web'de çalıştığı kanıtlanmış olan şeyleri yaparsınız ve bunları "makine" webine uygularsınız.
Büyük RPC (bağlı sorun tam uygulanması) 'de temelde yatan Distributed Computing Mugalataları'nın daha ayrıntılı olarak açıklanmıştır, teknik inceleme Arnon Rotem-Gal-Oz tarafından bu :
- Ağ güvenilir
- Gecikme sıfır
- Bant genişliği sonsuzdur
- Ağ güvenli
- Topoloji değişmez
- Bir yönetici var
- Nakliye maliyeti sıfır
- Ağ homojendir
Bunların hepsi yeni gelenlerin tipik olarak dağıtılmış sistemler oluşturmaya başladığında yaptıkları varsayımlardır. Tabii ki hepsi yanlış. Ve dağıtılmış sistemler oluştururken hepsini dikkate almanız gerekir.
Birçok RPC uygulamasındaki sorun, uzak aramaları yerel aramalara benzetmeye çalışmaktır. Ancak bunlar birbirine benzemez:
- yerel bir çağrı asla başarısız olmaz; altprogram Eğer başarısız olabilir denilen, ancak arama kendisini asla yok - Uzak çağrı ağda kaybolabilir
- yerel bir çağrı anlıktır; altprogram Aradığına uzun süre çalışabilir (hatta sonsuza kadar sonsuz döngüye sıkışmış alırsa), ancak arama kendisi çağrı ise daha az, en fazla kuyu (tüm CPU talimatları bir avuç hiçbir zaman alır satır içi, ancak çok hızlı) - uzak bir görüşme ağda uzun süre kalabilir
- altyordam normal bir şekilde dönerse, sonuç her zaman geri döner - uzak arama ile, sonuç ağda kaybolabilir
- iadeler anlıktır - uzaktaki sonuçlar ağda uzun süre seyahat edebilir
- bir alt rutini bir kez ararsam, tam olarak bir kez çalışır - uzaktaki bir çağrı ağda kaybolabilir veya çoğaltılabilir, böylece uzak rutin 0 ile istediğiniz sayıda çalışabilir
- Tam bir sonucu geri alıyorum - uzak bir sonuç kaybolabilir veya çoğaltılabilir, bu nedenle sonucu 0 veya daha fazla kez alabilirsiniz
- iki kez bir altyordam çağırırsam, iki sonuç alırım ve ikinci aramanın sonucundan önce ilk aramanın sonucunu alırım - muhtemelen şimdiye kadar tahmin edebilirsiniz: RPC ile, hiçbir sonuç alamayabilir veya sadece ilk , ya da sadece ikincisi, ya da birinciden önceki ikincisi ya da birincisi kaybolabilir ve ikincisini iki kez ya da başka bir şekilde elde edersiniz, vb.
- Eğer ararsam
ave sonra b, sonucunu ave ardından sonucunu geri alırım b - bu önceki noktanın sadece daha genel bir versiyonudur, RPC ile, herhangi bir sırayla 0 veya daha fazla kez iki cevaptan herhangi birini alabilirsiniz
Sen edecek bir uzaktan çağrı için yukarıdaki hepsi ile uğraşmak zorunda. Ancak çerçeveniz uzaktan aramaları yerel aramalardan ayırt edilemez yaparsa , yapamazsınız , çünkü hangilerinin uzak arama olduğunu bilmiyorsunuz . Çerçeve, sizin için bunların hepsini halledebilir, ancak sorun şudur: çerçeve, sisteminiz hakkında sizin kadar çok şey bilmiyor. Arada bir kişinin kaybolup kaybolmadığının önemli olmadığı çağrılar olup olmadığını bilmiyor. Dolayısıyla, çerçeve çok savunmacı olmak zorundadır ve bu gecikme ve bant genişliği açısından pahalıdır.
Özellikle çerçeve aslında beri edemez seni kalkan. CAP Teoremi dağıtılmış sistem, Tutarlı Temin ve Bölme Toleranslı aynı anda olamayacağını söyler; daha doğrusu, bir Bölüm oluştuğunda, sistemin hem Tutarlı hem de Kullanılabilir olmaya devam edemeyeceğini, birini seçmesi gerektiğini (popüler inanışın aksine, teorem sistem çalışırken üçüne de sahip olamayacağınızı söylemez. normalde, üçüne de sahip olabilirsiniz ; ancak bir Bölüme sahip olduğunuzda, diğer ikisinden birini seçmeniz gerekir). PACELC Teoremi sistemi çalışıyor olsa bile, trade-off Gecikme Tutarlılık vs sahip olduğunu göstererek CAP Teoremi uzanır.
Bunlar, alana özgü ve temel tasarım için önemli oldukları için çerçevenin sizi koruyamayacağı önemli ödünleşmelerdir.
Erlang en gibi bir yaklaşımla Bunun tam tersi, does Erlang, Binaların tüm mesaj uzak olarak kabul edilir gönderir, yerel olsa bile. Bu, her zaman yukarıdaki sorunların hepsini (ve daha fazlasını) ele almaya hazır olduğunuz anlamına gelir. Yerel süreçler için, bu do olsa bir yükü biraz oluşturmaktadır. Buna yardımcı olmak için, hata işleme ve denetimi ile uğraşmak için çok sayıda araç, çerçeve, kitaplık, desen ve deyim vardır.
RPC çerçevenizin özellikle nasıl çalıştığını ve hangi dil veya kütüphaneleri kullandığınızı açıklamıyorsunuz, ancak eski "ağ varmış gibi davran" türüne ait olduğuna dair güçlü bir şüphem var. Bunlar işe yaramıyor. Her şeyi uzaktan arama olarak değerlendirerek yerel ve uzak aramalar arasındaki ayrımı kaldırmak iyidir . Çok fazla o özetler tersi yapmak: ağ olduğunu aslında o soyut uzak bir şey, uzak sen soyut bile, sistemin bir parçası ihtiyaç hakkında bilmek.
Şimdi, özellikle REST kullanmanız gerekip gerekmediği , bu tamamen farklı bir soru. Yukarıda açıklandığı gibi, web DİNLENME için tasarlanmış ve iki yüzden DİNLENME, web için tasarlanmış yapmak birlikte mantıklı, ancak isterseniz, diğer mimari stilleri kullanabilirsiniz. Ancak sorunuzun en azından bir kısmı "neden RPC değil" ile ilgiliydi ve yukarıdaki nedenleri ortaya koydum, daha kesin olarak , kullandığınızdan şüphelendiğim RPC türünün neden başınız belaya girebileceğini açıkladım .