WSDL vs REST Artıları ve Eksileri

İlişkili:

Neden Web servisleri yerine REST kullanılır?

SOAP veya REST kullanarak bir web hizmeti uygulayıp uygulamayacağıma karar verirken (bununla RESTful bir şekilde HTTP / XML'i kastediyorum) nelere dikkat etmeliyim ve neyi düşünmeliyim? Bunun tek bir beden olmadığını varsayıyorum, bu yüzden hangisini kullanacağımı nasıl seçeceğim.

İki protokolün gerçek dünyada çok farklı kullanımları vardır.

SABUN (WSDL kullanan), belge geçirme etrafında ortalanmış olan ağır bir XML standardıdır. Bunun avantajı, isteklerinizin ve yanıtlarınızın çok iyi yapılandırılabilmesi ve hatta bir DTD kullanabilmesidir. Olumsuz yanı, XML olması ve çok ayrıntılı olmasıdır. Bununla birlikte, iki tarafın katı bir sözleşmeye sahip olması gerekiyorsa bu iyidir (örneğin, bankalar arası iletişim için). SOAP ayrıca belgelerinize WS-Security gibi şeyleri katmanlamanıza izin verir. SOAP genellikle aktarımdan bağımsızdır, yani HTTP kullanmanız gerekmez.

REST çok hafiftir ve çalışmasını sağlamak için HTTP standardına güvenir. Yararlı bir web hizmetini hızlı bir şekilde hazırlayıp çalıştırmak harika. Katı bir API tanımına ihtiyacınız yoksa, gitmenin yolu budur. Çoğu web hizmeti bu kategoriye girer. API'nizi, eski sürümleri kullanan kişiler için API güncellemelerini bozmayacak şekilde (bir sürüm belirttikleri sürece) sürümleyebilirsiniz. REST esas olarak HTTP gerektirir ve biçimden bağımsızdır (yani XML, JSON, HTML vb. Kullanabilirsiniz).

Genelde REST kullanıyorum çünkü süslü WS- * özelliklerine ihtiyacım yok. SOAP, bilgisayarların bir WSDL kullanarak web hizmetinizi anlamasını istiyorsanız iyidir. REST spesifikasyonları genellikle yalnızca insan tarafından okunabilir.

Aşağıdaki bağlantılar, Artıları ve Eksileri dahil olmak üzere WSDL ve REST hakkında yararlı bilgiler sağlar

Birkaç önemli nokta şudur:

1) SOAP, REST'in noktadan noktaya bir ortam için tasarlandığı dağıtılmış bir hesaplama ortamı için tasarlanmıştır.

2) WADL, REST hizmetleri için arabirimi tanımlamak için kullanılabilir.

http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and -wadl

WSDL ile ilgili olarak ("SABUN" anlamına gelir) "ağır" olarak. Ağır ne kadar önemli? Araç seti sizin için tüm "ağır işleri" yapıyorsa, o zaman neden önemlidir?

Henüz karmaşık bir REST API kullanmaya hiç ihtiyaç duymadım. Bunu yaptığımda, araçlarımın memnuniyetle bir dizi proxy sınıfına dönüştüğü bir WSDL dileyeceğimi umuyorum, böylece sadece yöntem gibi görünenleri arayabilirim. Bunun yerine, önemsiz olmayan REST tabanlı bir API kullanmak için, elle önemli miktarda "hafif" kod yazmak gerekeceğinden şüpheleniyorum.

Bunların hepsi yapıldığında bile, yine de insan tarafından okunabilir belgeleri koda çevirmiş olacaksınız ve tüm görevli insanların onu yanlış okuması riski vardır. WSDL, hizmetin makine tarafından okunabilen bir açıklaması olduğundan, "yanlış okumak" çok daha zordur.

Sadece bir not: bu yazı beri, gelmiş bir orta karmaşık DİNLENME hizmetiyle işe fırsatı buldu. Gerçekten bir WSDL veya eşdeğeri diledim ve gerçekten de elle çok fazla kod yazmak zorunda kaldım. Aslında, geliştirme süresinin önemli bir kısmı, farklı hizmet işlemlerini "elle" çağıran tüm kodun kod kopyasını kaldırmak için harcandı.

Bu muhtemelen yukarıdaki yazıların birçoğuna yorum olarak aittir, ancak bunu yapacak bir temsilcim henüz yok, işte burada.

Bence, SOAP ve REST için sıklıkla bahsedilen birçok artı ve eksinin (IMO) iki teknolojinin gerçek değerleri veya sınırları ile çok az ilgisi olması ilginçtir. Muhtemelen REST için en çok alıntı yapılan profesyonel, "hafif" olması veya daha "insan tarafından okunabilir" olma eğiliminde olmasıdır. Bir seviyede bu kesinlikle doğrudur, REST'in giriş için daha düşük bir engeli var - SOAP'tan daha az gerekli yapı var (yine de burada iyi aletlerin büyük ölçüde cevap olduğunu söyleyenlere katılıyorum - SOAP aletlerinin çoğu çok kötü oldukça korkunç).

Bununla birlikte, bu ilk giriş maliyetinin ötesinde, REST gösteriminin, istek URL'lerinin biçiminin ve çoğu REST hizmeti tarafından değiş tokuş edilen verilerin karmaşıklığının bir kombinasyonundan geldiğini düşünüyorum. REST, daha basit, daha fazla okunabilir istek URL'lerini teşvik etme eğilimindedir ve veriler de daha sindirilebilir olma eğilimindedir. Ancak bunlar ne ölçüde REST'e özgüdür ve ne dereceye kadar sadece rastlantısaldır. Daha basit URL yapısı, mimarinin doğrudan bir sonucudur - ancak aynı şekilde SOAP tabanlı hizmetlere de uygulanabilir. Daha sindirilebilir veriler, tanımlanmış herhangi bir yapının eksikliğinden kaynaklanıyor olabilir. Bu, veri formatlarınızı basit tutmanız veya çok iş yapacağınız anlamına gelir. İşte SOAP'ın ek yapısı,

Dolayısıyla, bilgisayar sistemleri arasında yapılandırılmış veri alışverişinde kullanmak için REST'in doğal olarak SOAP'tan (veya tam tersi) daha iyi olduğundan emin değilim, sadece farklılar. Bence yukarıdaki REST ve SOAP karşılaştırmasının dinamik ve statik yazım ile karşılaştırılması iyi bir şey. Dinamik dillerin sorun çıkma eğiliminde olduğu yerlerde, bir sistemin uzun vadeli bakımı ve bakımı söz konusudur (ve uzun vadede bir veya 2 yıldan bahsetmiyorum, 5 veya 10'dan bahsediyorum). REST'in zaman içinde aynı zorluklarla karşılaşıp karşılaşmayacağını görmek ilginç olacaktır. Dağıtılmış, bilgi işleme sistemi kuruyor olsaydım, iletişim mekanizması olarak SOAP'a yönelirim (ayrıca yukarıda bahsedildiği gibi sağladığı iletim ve uygulama protokol katmanlaması ve esnekliği nedeniyle) böyle olacağını düşünüyorum.

Diğer yerlerde REST daha uygun görünse de. İstemci ve sunucusu arasındaki AJAX (yükten bağımsız olarak) önemli bir örnektir. Bu tür bir bağlantının uzun ömürlülüğüne fazla özen göstermiyorum ve kullanım kolaylığı ve esneklik bir zamandır. Benzer şekilde, bazı harici hizmetlere hızlı erişime ihtiyacım olsaydı ve etkileşimin zaman içinde sürdürülebilirliğini umursamayacağımı düşünürsem (yine burada REST'in bana daha pahalıya mal olacağını varsayıyorum, bir şekilde veya başka), sonra REST'i seçebilirim, böylece hızlıca girip çıkabileyim.

Her neyse, ikisi de uygulanabilir teknolojilerdir ve belirli bir uygulama için yapmak istediğiniz değiş tokuşlara bağlı olarak size iyi (veya kötü) hizmet edebilirler.

REST bir protokol değildir; Bu mimari bir tarz. Ya da isterseniz bir paradigma. Bu, SABUN'un tanımının çok daha gevşek olduğu anlamına gelir. Temel CRUD için Atompub gibi standart protokollere güvenebilirsiniz, ancak çoğu hizmet için bundan daha fazla komuta sahip olacaksınız.

Tüketici olarak SOAP, dil desteğine bağlı olarak bir nimet veya lanet olabilir. SOAP çok sıkı bir şekilde yazılmış bir sistem üzerinde modellendiğinden, en iyi statik olarak yazılmış dillerle çalışır. Dinamik bir dil için, kolayca hırslı ve gereksiz hale gelebilir. Ek olarak, istemci kitaplığı desteği, Java ve .NET dünyası dışında o kadar iyi değil.

Bana göre web hizmeti kelimesini kullanırken dikkatli olmalıyız. SOAP web servisinden, REST web servisinden veya diğer web servislerinden bahsediyorsak, her zaman belirtmeliyiz çünkü burada farklı şeyler hakkında konuşuyoruz ve tüm web servislerini adlandırırsak insanlar artık anlamıyorlar.

Temel olarak SOAP web hizmetleri yıllardır çok iyi oluşturulmuştur ve SOAP spesifikasyonuna göre onlarla nasıl iletişim kuracaklarını açıklayan katı bir spesifikasyona sahiptirler. Şimdi REST web hizmetleri biraz daha yeni ve temelde daha basit görünüyor çünkü herhangi bir iletişim protokolü kullanmıyorlar. Temel olarak, bir REST web servisini kullandığınızda gönderdiğiniz ve aldığınız şey düz XML'dir. İnsanlar bundan hoşlanıyor çünkü SOAP gibi daha karmaşık bir iletişim protokolüyle uğraşmak zorunda kalmadan xml'yi istedikleri şekilde ayrıştırabiliyorlar.

Bana göre REST hizmetleri, bir SOAP web hizmeti yerine bir sunucu uygulaması oluşturmaya benziyor. Sunucu uygulaması verileri alır ve verileri geri döndürür. Verilerin formatı xml tabanlıdır. İstersek xml'den başka bir şey kullanmayı da hayal edebiliriz. Örneğin xml yerine etiketler kullanılabilir ve bu artık REST değil, başka bir şey olabilir (Ağırlık açısından daha hafif olabilir çünkü xml doğası gereği hafif değildir). Buna hala bir web hizmeti diyebilir miyiz? Evet yapabilirdik ama bu mevcut herhangi bir standardı takip etmeyecek ve buradaki ana mesele bu her şeyi web servisleri olarak adlandırmaya başlarsak ama istediğimiz gibi yapabiliriz, o zaman şeylerin birlikte çalışabilirlik tarafında kaybediyoruz. Bu, web hizmeti ile değiş tokuş edilen verilerin formatının artık standartlaştırılmadığı anlamına gelir.

İnsanların SOAP'tan hoşlanmadıkları şey, anlamakta güçlük çekmeleri ve sorguları manuel olarak üretememeleridir. Bilgisayarlar bunu çok iyi yapabilir, ancak bu yüzden net olmamız gereken yer burasıdır: Web hizmetleri sorguları ve yanıtlarının doğrudan son kullanıcılar tarafından kullanılması gerekiyor mu yoksa web hizmetlerinin bazı normalleştirilmiş bilgisayar sistemleri tarafından çağrılan API'nin altında olduğunu kabul ediyor muyuz? standartlar?

SABUN : Ayrıca SMTP aracılığıyla da taşınabilir, yani hizmeti E-posta basit metin biçimini kullanarak da çağırabiliriz

SABUN mesajını çeşitli dillerde ilgili nesne yapısına dönüştürmek için ek çerçeveye / motora ihtiyaç duyar.

REST : Artık WSDL2.0, REST web hizmetini de tanımlamayı destekliyor

Hizmetinizi hafif hale getirmek istediğinizde, örneğin cep telefonu, pda vb. Mobil cihazlardan arama yapmak istediğinizde kullanabiliriz ...

Sisteminizin kurumlarınız içinde sınırlı olduğu kurumsal sistemler için sabun kullanımı daha kolay ve doğrudur çünkü neredeyse müşterilerin kontrolü sizdedir. Sınıflar (vekiller) oluşturan ve java veya .net ortamınıza (çoğu şirketin kullandığı) uyan normal OOP'nizi yapıyormuşsunuz gibi görünen çeşitli araçlar olduğundan daha kolaydır.

İstemciler javascripts veya html veya yazmanın katı olmadığı diğerlerini kullanıyor olabileceğinden, arayüzleri açığa çıkarmak için internete dönük uygulamalar için (twitter api gibi) REST kullanırım. REST daha liberal olmak daha mantıklı.

Ayrıca internete bakan istemciler için (dünya çapında web), bir sabun arayüzünden gelen tamamen bir xml yerine bir dinlenme arayüzünden gelen json veya xml'yi ayrıştırmak daha kolaydır. javascript üzerinde proxy kullanmak zordur ve javascript doğal olarak nesneleri desteklemez. Javascript ile REST kullanıyorsanız, genellikle json dizesini ayrıştırırsınız ve kapanırsınız. İnternete bakan arayüzler genellikle çok basittir (bu nedenle çoğu zaman basit ayrıştırması) ve genellikle tutarlılık gerektirmez, bu nedenle REST yeterlidir.

Kurumsal uygulamalar için REST'in yeterli olduğunu düşünmüyorum çünkü işlemler, güvenlik, sıkı yazım, şemalar kurumsal uygulama geliştirmede çok önemli bir rol oynar, bu yüzden SOAP onlar için daha uygundur.

Sonuç olarak, SOAP Kurumsal sistemler için, REST İnternet veya WWW içindir. Onu birbirinin yerine kullanabilirsiniz, ancak sonunda iş için doğru aracı kullanmamakta zorlanabilirsiniz.

kötü ingilizcem için özür dilerim.

REST'in savunmasında, HTTP ve adreslenebilirlik ilkelerini yakından takip eder, örneğin okuma işlemleri GET kullanır, güncelleme işlemleri POST kullanır vb. Bunun çok daha temiz bir yaklaşım olduğunu düşünüyorum. Oreilly kitabı RESTful Web Services bunu benim elimden çok daha iyi açıklıyor, eğer okursanız REST yaklaşımını tercih edeceğinizi düşünüyorum

İstemci tarafındaki araç seti bir olacaktır. Ve SOAP hizmetlerine aşinalık diğeridir. Bu günlerde gittikçe daha fazla hizmet RESTful rotasına gidiyor ve bu tür hizmetleri test etmek basit cURL örnekleriyle yapılabilir. Bununla birlikte, her iki yöntemi de uygulamak ve istemcilerden en geniş şekilde yararlanmaya izin vermek o kadar da zor değildir.

Birini seçmeniz gerekiyorsa, REST'i öneririm, daha kolay.

Önceki cevaplar çok fazla bilgi içeriyor, ancak belirtilmeyen felsefi bir fark olduğunu düşünüyorum. SOAP, "RPC'nin modern, nesne yönelimli, platform ve protokolden bağımsız halefini nasıl yaratırız?" Sorusunun yanıtıydı. REST, "HTTP'yi web için bu kadar başarılı kılan içgörüleri nasıl alırız ve bunları dağıtılmış bilgi işlem için nasıl kullanırız?" Sorusundan geliştirilmiştir.

SOAP, dağıtılmış programlamanın programlamaya benzemesi için araçlar sağlamakla ilgilidir. REST, dağıtılmış arayüzleri basitleştirmek için bir stil empoze etmeye çalışır, böylece dağıtılmış kaynaklar, dağıtılmış html sayfalarının birbirine başvurabileceği gibi birbirine başvurabilir. Bunu yapmanın bir yolu, işlemleri (çoğunlukla) kaynaklar üzerindeki "CRUD" ile (oluşturma, okuma, güncelleme, silme) kısıtlama girişimidir.

REST hala gençtir - "insan tarafından okunabilir" hizmetlere yönelik olmasına rağmen, iç gözlem hizmetlerini vb. Veya otomatik proxy oluşturmayı dışlamaz. Ancak, bunlar standartlaştırılmadı (yazdığım gibi). SOAP size bunları verir, ancak (IMHO) size "yalnızca" bunları verirken, REST tarafından empoze edilen stil, basitliği nedeniyle zaten web hizmetlerinin yayılmasını teşvik ediyor. Yeni başlayan hizmet sağlayıcılarını, kullanmaları gereken belirli SABUN tarafından sağlanan özellikler olmadığı sürece REST'i seçmeye teşvik ederdim.

O halde, bana göre, bir "sıfırdan" API uyguluyorsanız ve olası istemciler hakkında pek bir şey bilmiyorsanız, arayüzleri anlaşılır ve geliştirmesi kolay hale getirmeye yardımcı olma eğiliminde olduğu için REST'i seçerim. İstemci ve sunucu hakkında çok şey biliyorsanız ve her ikisi için de hayatı kolaylaştıracak özel SOAP araçları varsa, o zaman REST konusunda dindar olmazdım.

Yalnızca yapılandırma ayarlarınızı değiştirerek WSDL-fışkıran WCF web bileşenlerinizi diğer kullanımlara kolayca geçirebilirsiniz. HTTP üzerinden geçebilir ve ardından kodunuzu değiştirmek zorunda kalmadan borular, tcp, özel protokoller vb. Adlandırabilirsiniz. WCF bileşenlerinin güvenlik, iki yönlü arama, işlemler, eşzamanlılık vb. Şeyler için daha kolay ayarlanabileceğine inanıyorum.

REST, sizi HTTP ile sınırlar (çoğu durumda bu iyidir).

Bu tartışmanın eski bir tartışma olduğunu biliyorum, ancak tüm cevapları okuduktan ve yorum yaptıktan sonra, herkesin 2 sistem arasındaki farkla ilgili en önemli noktayı gözden kaçırdığına inanıyorum: SOAP, yalnızca verileri vermekle kalmayıp aynı zamanda doğrulamak için karmaşık türleri kullanır ve tanımlandığı katı tip tanımlamasında saklayın. WSDL size veri formatının ne olduğunu, veri türünün ne olduğunu söyler, reg-ex kalıp stili kuralları eklemenize izin verir ve bir istek / yanıtta bir veri parçasına kaç kez izin verilmesi gerektiğini ve izin verilebileceğini tanımlar. . Öte yandan dinlenme bu mekanizmaların hiçbirine sahip değildir.

SOAP karmaşık ve ağırdır çünkü karmaşık ağır hiyerarşik verileri göndermenize izin verir. REST, başlangıç ​​ve bitiş noktası kuralları sıralayan düz metindir.

SOAP işten bağımsızdır, çünkü belgeye gömülü tüm veri kurallarına sahiptir.

SABUN ve REST arasındaki fark, SABUN'un kendi kendine yeten iş odaklı bir şema olmasıdır. REST bir metin belgesidir.