RPC-ish yaklaşımları ne zaman REST'ten daha uygun olur?

Steve Vinoski'nin REST, Reuse ve Serendipity konusundaki bu konuşmasını izledikten sonra , (XML-) RPC-ish kurulumları için yeşil alan projelerinde iş vakaları olup olmadığını merak ediyorum , REST daha iyi çözemedi.

Birkaç RPC-Probleminden bahseder:

• Dile odaklanın (dağıtılmış sistemi dile değil, dile çevirin)
• "Yerel görünmesini sağlayın" (ve kural yerine istisnalar olarak başarısızlık ve gecikmeyle başa çıkın)
• dilden bağımsız olması amaçlanmıştır ancak ana bileşen olarak diller arasında hala "işlev çağrıları" vardır
• IDL kazan plakası
• Tip emniyet yanılsaması
• ve birkaç tane daha ...

Sadece biraz dramatize etmek için, RPC ve REST için bazı Google Anında Arama sonuçları:

Genel olarak, RPC, REST'ten çok bir dil entegrasyonu sunar. Bahsettiğiniz gibi, bu, özellikle tek bir dağıtılmış sistem, birden fazla dilde yazılmış kod çalıştıran birden fazla ana bilgisayarı içerdiğinde, ölçeklendirme, hata işleme, tür güvenliği vb. Bununla birlikte, RPC, REST ve hatta her ikisini de aynı anda kullanan iş sistemleri yazdıktan sonra, bazı durumlarda RST'yi seçmek için RPC'yi seçmek için iyi sebeplerin olduğunu buldum.

İşte RPC’yi daha iyi bir şekilde bulduğum durumlar:

• Sıkı bağlama. Sistemin (dağıtılmış) bileşenleri birlikte çalışmak üzere tasarlanmıştır ve birinin değiştirilmesi diğerlerini de etkileyecektir. Bileşenlerin gelecekte diğer sistemlerle iletişim kurmak üzere adapte edilmesi gerekme olasılığı düşüktür.
• Güvenilir iletişim Bileşenler birbirleriyle tamamen aynı ana bilgisayarda ya da gecikme sorunları, paket kaybı, vb. Yaşanması muhtemel olmayan bir ağ üzerinde iletişim kuracaklar.
• Düzgün dil Tüm (veya çoğunlukla hepsi) bileşenler tek bir dilde yazılacaktır. Gelecekte, farklı bir dilde yazılmış ek bileşenlerin eklenmesi muhtemel değildir.

IDL ile ilgili noktaya gelince, bir REST sisteminde ayrıca, REST taleplerindeki verileri ve cevapları, kullandığınız dahili veri temsiline dönüştüren bir kod yazmanız gerekir. IDL kaynakları (iyi yorumlar ile) ayrıca, bir REST API için ayrı ayrı yazılması ve muhafaza edilmesi gereken arayüzün dokümantasyonu olarak da kullanılabilir.

Yukarıdaki üç öğe genellikle daha büyük bir sistemin bir bileşenini oluşturmak istediğinizde ortaya çıkar. Tecrübelerime göre, bu bileşenler çoğu zaman alt sistemlerinin bağımsız olarak başarısız olması ve diğer alt sistemlerin veya tüm bileşenin tamamen arızalanmasına neden olmaması gereken bileşenlerdir. Birçok sistem de bu hedeflere ulaşmak için Erlang'da yazılmıştır ve bazı durumlarda Erlang bir sistemi başka bir dilde yazmaktan ve sadece bu faydaları elde etmek için RPC'yi kullanmaktan daha iyi bir seçim olabilir.

Çoğu mühendislik problemi gibi, süreçler arası iletişim problemine tek bir çözüm yoktur. Tasarladığınız sisteme bakmanız ve kullanım durumunuz için en iyi seçimi yapmanız gerekir.

Ürünler bir veri merkezinde ölçeklendirildiğinde ve yüksek kullanılabilirlik ve yük dengelemesi yaptığınızda REST'in bazı büyük avantajları vardır.

Ancak, daha küçük ölçekli bir proje düşünün. Saatte birkaç yüz talepte bulunacak bir web servisine mi ihtiyacınız var? WCF tüm ulaştırma konularıyla ilgilenir. Ağ üzerinden nesneler göndermek için uygun bir arayüze sahiptir ve sadece application.config dosyasını kullanarak ağ bağlantısının sıfır programlama ile yapılandırılmasına, şifrelenmesine ve sertifikalandırılmasına izin verir.

Aslında ikisine de sahip olabilirsin. RestRPC for Grails gibi Eklentiler, çağrılarınızı arama yöntemlerine göre kesecek ve istediğiniz kadar dinlemenize izin verirken (ki bu RPC'ye çok benzer) izin verir.