RESTful mimarisinin Artıları ve Eksileri [kapalı]

REST'in artıları ve eksileri ile ilgili olarak gördüğüm en yaygın tartışma, bu tartışmayı SOAP'a göre çerçeveleme eğilimindedir. Ben de tecrübem yok. Şu anda deneyim eksikliğimin değerlendirmesini zorlaştırdığı bir kararla karşı karşıyayım. Birkaç bileşen - öncelikle sahibinin birkaç siteyi yönetmesine izin veren bir yönetimsel yönü - ve kullanıcının ana bilgisayarda tutulan verilerle etkileşime girmesini sağlayan halka açık bir kullanıcı arabirimi içeren bir uygulama geliştirmeye başlıyorum. İkinci bölümün herhangi bir yerde barındırılmasına izin vermenin ve RESTful mimarisi ile eski ile iletişim kurmanın ya da her iki bileşenin de aynı ana bilgisayarda bulunmasını talep etmenin sonuçlarını değerlendirmem gerekiyor. RESTful mimarisini geliştirmenin, özellikle aşağıdaki alanlardaki kapasitesi ile ilgili temel sonuçları nelerdir:

1: Güvenlik 2: Performans 3: Arayüz karmaşıklığı

EDIT: Bu sorunun bazı cevaplarına bakarak - açıklığa kavuşturmak gerekir. SOAP ile bir karşılaştırma aramıyorum - daha ziyade tüm bileşenlerin bir ana bilgisayarda bulunduğu uygulamalara karşı REST uygulamalarına genel bakış. (bu cevaplar için teşekkürler!)

Bu alanlar göz önüne alındığında, kabaca bir genel bakış sunabilirim, ancak sonuçlarınızı sizin için çıkaramıyorum. İki protokolün farklı olduğu iki ana alan vardır:

• Mesaj biçimi
• Hizmet keşfi

Mesaj formatını anlamak en kolay yoldur. Hem istek hem de yanıt için SOAP ambalajı oldukça ağırdır. Hem üstbilgi hem de gövde bölümü içeren SOAP zarfı var. Başlık, bir tür tanımlama, yetkilendirme vb. Gerçekleştirmek için istek zincirindeki birkaç filtre tarafından kullanılabilir. Bununla birlikte, XML'nin ayrıştırılması pahalıdır, bu da sisteminizin ölçeklenebilirliğine belirli bir ceza verir. Yığındaki SOAP işleme katmanına ne kadar bağlı olduğu.

Hizmet keşfi, muhtemelen en fazla çekişme yapacağınız yerdir. REST, doğası gereği öngörülebilir bitiş noktaları sağlar ve isteğin içeriği basit bir HTTP isteğidir. Bunun yararı, ek bir ek yük olmamasıdır ve son kullanıcılar, sitenizin URL yapısını anladıktan sonra ihtiyaç duydukları şeyi nasıl yapacaklarını tahmin edebilirler. Tabii ki, saf güvenlik bilinçli insanlar bunu bir zayıflık olarak görecekler. Afterall, SOAP ile, uç noktaların ne olduğunu bilmek için bir WSDL tüketmelisiniz. Tabii ki, SOAP ile size daha fazla hedefli saldırılar yapabilmeniz için mesaj biçiminin tamamı verildi.

Verdiğiniz kategorilere göre ayrılmış:

Güvenlik

İkisi de doğal olarak diğerinden daha güvenli değildir. İyi güvenlik ilkeleri kullanın:

• İletişimleri şifrele
• İşleme koymadan önce kullanıcıların kimliğini doğruladığınızdan ve yetkilendirdiğinizden emin olun
• Doğrudan saldırıları önlemek için iyi kodlama alışkanlıkları
• Ve bu sadece kısa liste.

Belirsizliği hatırlayın! = Güvenlik.

Verim

Ham performans ve ölçeklenebilirlik, basit HTTP protokollerini izleyen istek nedeniyle REST'e gidecektir. Çoğu SOAP yığını, SOAP yığınlarının ölçeklendirilebilirliğini büyük ölçüde artıran SAX ayrıştırma (olay ayrıştırma) kullanır, ancak ek yük üzerinde ölçülebilir bir etki vardır. SOAP, XML ayrıştırma ek yüküne ek olarak normal HTTP işleme yüküne sahiptir. REST'in yalnızca HTTP işlem yükü vardır.

karmaşa

Sistem açısından REST kazanır. Daha az hareketli parça, daha zayıf bir talep zinciri vb. Vardır. Bu, güvenilir hale getirmenin daha kolay olduğu anlamına gelir.

Programcı bakış açısından, kullandığınız IDE veya çerçeve ona iyi bir destek sağlıyorsa SOAP kazanabilir. Esasen, REST ile ön işlem çalışmalarını (kimlik doğrulama / yetkilendirme / vb.) Gerçekleştirirken, SOAP ile bunların çoğu takılabilir bir işlem zinciri ile gerçekleştirilebilir.

Benim tercihim

HTTP istekleri konusunda çok rahatım ve web'in nasıl çalıştığını biliyorum. Sonuç olarak, REST yaklaşımı benim için daha çok tercih edilir. Ancak, bazı müşterilerimin bundan rahatsız olduğunu biliyorum. REST vs. SOAP vb. Nin güvenliğini kınayan bazı endüstri makalelerini okudular. Uygulamanın olması gerektiği kadar güvenli olduğundan emin olmak sizin elinizde. Açıkçası, bir sosyal web uygulaması bir banka veya hükümet sistemi kadar güvenlik talep etmez (veya arzu etmez). Pek çok SOAP yığını, bir miktar güvenlik görünümü sağlamak için takabileceğiniz işlemciler içerir, ancak bunları aramak ve yerine koymak yine de sizin sorumluluğunuzdadır.

1. Güvenlik: HTTPS kullanın. Bu her ikisi için de geçerlidir.
2. Performansı: . REST daha az CPU pahalıdır (daha az ayrıştırma, sıralama, açılma). Ayrıca, REST ile önbellek yapmak çok kolay.
3. Karmaşıklık: REST kurulum açısından daha az talep eder, sonuçta sadece GET / POST. SOAP, bakımı için daha fazla yönetim gerektirir (wsdl vb.), Ancak IDE'niz destekliyorsa biraz daha kolaydır.

Ben REST ve bazı içerik / mime türleri ile aynı şeyi yapabilirsiniz SOAP çok şişirilmiş olduğunu düşünüyorum . Ayrıca, SOAP, sarmalayıcıların doğası ve daha genel olması ve HTTP ile sınırlı olmaması nedeniyle çok fazla yük getirir. SOAP, IDE'niz düzgün bir şekilde destekliyorsa ve HTTP öğrenmek istemiyorsanız cazip gelebilir. Ama benim için REST'in kullanımı çok daha kolay ve çok daha web dostu.

Günümüzde, kullanmak için çok iyi REST API'leri var. Java'ya giriyorsanız, Jax-RS gerçekten harika. Bazı insanlar için bu porno gibidir.

REST'in en büyük avantajının RPC mimarilerinden kopmak olduğunu düşünüyorum. REST, süreçleri değil kaynakları ortaya çıkarır. Bu, bir parçanın değişikliklerinin, iyileştirmelerinin, hatta arızalarının diğer parçalar üzerinde sınırlı (olumsuz) etkiye sahip olduğu gevşek bağlı bir sistem oluşturmanıza olanak tanır.

Ne yazık ki, REST'in yaygın bir kötüye kullanımı, iç veri yapılarınızı ortaya çıkarmaktır (en kötü durumda, veritabanınızın bir CRUD'sidir, ugh). Bu güvenli bir şekilde yapmayı çok zorlaştırır. 'Doğru' kullanım, ele aldığınız sistemin parçasıyla ilgili yüksek düzeyli nesneleri ortaya çıkarmak ve tutarsızlık durumunda liberal olarak hata durum kodlarını döndürmektir.

REST'in sıklıkla gözden kaçan bir diğer kısmı, çoğu fiilin idempotensidir. Sadece GET değil, aynı zamanda bir veya birkaç kez uygulanırsa PUT ve DELETE tam olarak aynı sonuç olmalıdır (zaten silinmişse 404'ü veya istemci aynı PUTting yapıyorsa 'değişiklik yok'). Bu, sağlam sistemlere ve anlambilimin kesin yorumlarının daha az karşılıklı bağımlılığına yol açar.

WS- * standartları gerçekten RAP'yi SOAP / HTTP üzerinden çalıştırmakla ilgilidir. Böylece, CORBA ve J2EE ve seleflerine giren tüm düşünceler çoğunlukla XML'de aynı tür şeyleri yapmaya yöneldi. Bu, tür bildirimleri ve hizmet sözleşmeleri, meta veri alışverişi, bildirici güvenlik vb. Açıkçası işletmede bile aşırı kullanılmış.

Sizin gibi bir internet web uygulaması yapan insanlar, RESTful mimarisini kullanmaktan kesinlikle daha iyi olurdu. Hemen hemen her platform onu ​​kullanabilir ve hangi spesifikasyonu kullandığınızı ve araca özgü tip dönüşüm tuhaflıkları vb.

Mevcut REST uygulamaları üzerinde SOAP'ın tek büyük avantajı, SOAP'ın daha kolay bir şekilde kullanılabilmesidir - çoğu RESTful müşterisi arayüzü anlamamı ve bir tür istemci yazmamı gerektirir. SOAP için, ben sadece ona wsdl.exe işaret ve benim için sınıf oluşturur.