REST Web Servisleri yapmak için daha iyi bir yaklaşım mı yoksa SOAP mı? Yoksa farklı problemler için farklı araçlar mı? Ya da nüanslı bir konu mu - yani, belirli arenalarda biri diğerinden biraz daha iyi, vb.

Özellikle bu kavramlar ve PHP-evren ve modern üst düzey web uygulamaları ile olan ilişkileri hakkında bilgi için teşekkür ederiz.

Hewlett-Packard'da çalışırken kod oluşturma ve WSDL üretimi de dahil olmak üzere ilk SOAP sunucularından birini orijinal spesifikasyonundan geliştirdim. SABUN bir şey için kullanmanızı önermiyoruz.

"SOAP" kısaltması bir yalandır. Basit değil, Nesne yönelimli değil, Erişim kuralları tanımlamıyor. Bu tartışmalı bir Protokol. Don Box'ın şimdiye kadarki en kötü özelliğidir ve "COM" yapan adam olduğu için bu oldukça başarılıdır.

SOAP'ta taşıma için REST ve veri sunumu için JSON, XML ve hatta düz metin ile yapılamayan hiçbir şey yoktur. Taşıma güvenliği için https kullanabilirsiniz. Kimlik doğrulama için temel kimlik doğrulama. Oturumlar için çerezler vardır. REST sürümü daha basit, daha net, daha hızlı çalışacak ve daha az bant genişliği kullanacaktır.

XML-RPC, istek, yanıt ve hata protokollerini açıkça tanımlar ve çoğu dil için iyi kütüphaneler vardır. Ancak, XML birçok görev için gerekenden daha ağırdır.

REST bir mimari, SOAP bir protokoldür.

Bu ilk sorun.

Bir REST uygulamasında SOAP zarfları gönderebilirsiniz.

SOAP'ın kendisi aslında oldukça basit ve basit, üstünde WSS- * standartları çok karmaşık.

Tüketicileriniz başka uygulamalar ve diğer sunucularsa, bugün SOAP protokolü için çok fazla destek var ve veri taşımanın temelleri modern IDE'lerde bir fare tıklaması.

Tüketicilerinizin RIA veya Ajax istemcisi olma olasılığı daha yüksekse, muhtemelen SOAP'tan daha basit ve istemciye özgü (özellikle JSON) bir şey isteyeceksiniz.

HTTP üzerinden gönderilen JSON paketleri mutlaka bir REST mimarisi değildir, sadece URL'lere mesaj gönderir. Hepsi mükemmel bir şekilde uygulanabilir, ancak REST deyiminin kilit bileşenleri vardır. Ancak ikisini karıştırmak kolaydır. Ancak HTTP istekleri hakkında konuşmanız, bir REST mimarisine sahip olduğunuz anlamına gelmez. Hiç HTTP olmayan bir REST uygulamanız olabilir (bu nadirdir).

Yani, SOAP ile "rahat" sunucularınız ve tüketicileriniz varsa, SOAP ve WSS yığını size iyi hizmet verebilir. Daha fazla geçici şeyler yapıyorsanız ve web tarayıcıları ile daha iyi arayüz oluşturmak istiyorsanız, HTTP üzerinden daha hafif bir protokol de iyi çalışabilir.

REST, SOAP'tan temelde farklı bir paradigmadır. REST hakkında iyi bir okuma burada bulunabilir: REST'i eşime nasıl açıkladım .

Okumak için zamanınız yoksa, işte kısa versiyon: REST, "isimler" e odaklanarak ve bu isimlere uygulayabileceğiniz "fiillerin" sayısını kısıtlayarak bir paradigma değişikliğidir. İzin verilen fiiller "get", "put", "post" ve "delete" dir. Bu, birçok farklı fiilin (yani birçok farklı fonksiyona) uygulanabildiği SOAP'tan farklıdır.

REST için, dört fiil karşılık gelen HTTP istekleriyle eşlenirken, isimler URL'ler tarafından tanımlanır. Bu durum yönetimini, sunucuda hangi durumun ve istemcide ne olduğu genellikle belirsiz olan SOAP'tan çok daha şeffaf hale getirir.

Pratikte bunun en uzağa düşüyor olsa ve DİNLENME genellikle sadece olumsuzlukları beraberinde getirmektedir kadar basit HTTP istekleri ifade eder JSON , SOAP daha karmaşık bir API ise o etrafında XML geçirerek ile iletişim kurmaktadır. Her ikisinin de avantajları ve dezavantajları var, ancak deneyimlerime göre REST'in genellikle daha iyi bir seçim olduğunu gördüm, çünkü nadiren SOAP'tan aldığınız tam işlevselliğe ihtiyacınız varsa.

2012 sorusu için hızlı indirme:

REST'in gerçekten iyi çalıştığı alanlar:

• Sınırlı bant genişliği ve kaynaklar. Dönüş yapısının gerçekten herhangi bir biçimde olduğunu unutmayın (geliştirici tanımlı). Ayrıca, REST yaklaşımı standart GET, PUT, POST ve DELETE fiillerini kullandığından herhangi bir tarayıcı kullanılabilir. Yine, REST'in günümüzde çoğu modern tarayıcının desteklediği XMLHttpRequest nesnesini kullanabileceğini ve bu da AJAX için ekstra bir bonus eklediğini unutmayın.

• Tamamen vatansız operasyonlar.  Bir işlemin sürdürülmesi gerekiyorsa, REST en iyi yaklaşım değildir ve SOAP buna daha iyi uyabilir. Ancak, durum bilgisi olmayan CRUD (Oluşturma, Okuma, Güncelleme ve Silme) işlemlerine ihtiyacınız varsa, REST budur.

• Önbellekleme durumları.  REST yaklaşımının tamamen vatansız çalışması nedeniyle bilgiler önbelleğe alınabiliyorsa, bu mükemmeldir. Bu, yukarıdaki üçte çok fazla çözümü kapsar.

Öyleyse neden SOAP'ı düşüneyim ki? Yine, SOAP oldukça olgun ve iyi tanımlanmış ve eksiksiz bir şartname ile geliyor. REST yaklaşımı sadece bir yaklaşımdır ve gelişime açıktır, bu nedenle aşağıdakilere sahipseniz SOAP harika bir çözümdür:

• Zaman uyumsuz işleme ve çağırma.  Uygulamanızın garantili bir güvenilirlik ve güvenlik düzeyine ihtiyacı varsa, SOAP 1.2 bu tür bir işlem sağlamak için ek standartlar sunar. WSRM gibi şeyler - WS-Güvenilir Mesajlaşma.

• Resmi sözleşmeler.  Her iki tarafın (sağlayıcı ve tüketici) değişim formatı üzerinde anlaşması gerekiyorsa, SOAP 1.2 bu tür etkileşim için katı özellikler verir.

• Durumsal işlemler. Uygulamanın içeriksel bilgi ve konuşma durumu yönetimi gerekiyorsa SOAP 1.2, WS * yapısında bu şeyleri (Güvenlik, İşlemler, Koordinasyon vb.) Desteklemek için ek spesifikasyona sahiptir. Nispeten, REST yaklaşımı geliştiricilerin bu özel sıhhi tesisatlarını inşa etmesini sağlayacaktır.

http://www.infoq.com/articles/rest-soap-when-to-use-each

SOAP şu anda, hem hizmet katmanı için hem de herhangi bir WSDL'den istemciler oluşturmak için çok sayıda kazan plakası kodu üretecekleri daha iyi araçlara sahiptir.

REST daha basittir, sonuç olarak bakımı daha kolay olabilir, Web mimarisinin kalbinde yer alır, daha iyi protokol görünürlüğü sağlar ve WWW'nin boyutunda ölçeklendiği kanıtlanmıştır. Dışarıdaki bazı çerçeveler Ruby on Rails gibi REST hizmetlerini oluşturmanıza ve hatta bazıları ADO.NET Veri Hizmetleri gibi yazma istemcileri konusunda size yardımcı olur. Ancak, çoğunlukla, araç desteği eksiktir.

SOAP, takım bakış açısından yararlıdır, çünkü WSDL araçlar tarafından çok kolay tüketilir. Böylece, en sevdiğiniz dilde Web Hizmeti istemcilerinin sizin için oluşturulmasını sağlayabilirsiniz.

REST, AJAX'ın web sayfalarında iyi oynar. İsteklerinizi basit tutarsanız, doğrudan JavaScript'inizden servis aramaları yapabilirsiniz ve bu çok kullanışlı olur. Yanıt XML'inizde ad alanlarından uzak durmaya çalışın, tarayıcıların bunlara boğulduğunu gördüm. Yani, xsi: type muhtemelen sizin için çalışmayacak, aşırı karmaşık XML Şemaları yok.

REST de daha iyi performans gösterir. REST yanıtları üreten kodun CPU gereksinimleri, SOAP çerçevelerinin gösterdiklerinden daha düşük olma eğilimindedir. Ayrıca, sunucu tarafında XML oluşturma ördekleriniz varsa, XML'i etkin bir şekilde istemciye aktarabilirsiniz. Yani, veritabanı imlecinin satırlarını okuduğunuzu düşünün. Bir satırı okurken, bunu bir XML öğesi olarak biçimlendirirsiniz ve bunu doğrudan hizmet tüketicisine yazarsınız. Bu şekilde, XML çıktısını yazmaya başlamadan önce tüm veritabanı satırlarını bellekte toplamak zorunda kalmazsınız - aynı anda hem okur hem de yazarsınız. Akışın REST için çalışmasını sağlamak için yeni şablon motorlara veya XSLT'ye bakın.

Öte yandan SOAP, araç tarafından oluşturulan hizmetler tarafından büyük bir damla olarak oluşturulma ve ancak daha sonra yazılma eğilimindedir. Bu mutlak bir gerçek değildir, unutmayın, ekleri kullanmak gibi SOAP'tan akış özelliklerini almanın yolları vardır.

Karar verme sürecim şu şekildedir: hizmetimin tüketiciler tarafından kolayca işlenmesini istiyorsam ve yazdığım iletiler orta-küçük-ish (10MB veya daha az) olacak ve fazladan bir CPU yazmayı umursamıyorum sunucu üzerinde döngüleri, ben SOAP ile gidin. Web tarayıcılarında AJAX'a hizmet etmem gerekiyorsa veya akış için bir şeye ihtiyacım varsa veya yanıtlarım devasa ise, REST'e giderim.

Son olarak, doğru araçları kullanıyorsanız, takabileceğiniz WS-Security ve durum bilgisi olan Web Servisleri almak gibi SOAP etrafında oluşturulmuş birçok büyük standart vardır. Bu tür şeyler gerçekten bir fark yaratır ve bazı tüylü gereksinimleri karşılamanıza yardımcı olabilir.

Bunun eski bir soru olduğunu biliyorum ama cevabımı göndermeliyim - belki birisi faydalı bulabilir. Kaç kişi SABUN REST tavsiye ediyoruz inanamıyorum. Bu insanların yalnızca geliştirici olmadığını veya hiçbir zaman makul boyutta bir REST hizmeti uygulamadığını varsayabilirim. Bir REST hizmetinin uygulanması, bir SOAP hizmetini uygulamaktan çok daha uzun sürer. Ve sonunda da çok daha karışık oluyor. Zamanın% 99'unda SOAP'ı seçmemin nedenleri:

1) Bir REST hizmetinin uygulanması, bir SOAP hizmetinin uygulanmasından çok daha uzun sürer. WSDL'de okumak ve proxy sınıfları ve istemcileri çıkarmak için tüm modern diller / çerçeveler / platformlar için araçlar mevcuttur. Bir REST hizmetinin uygulanması elle yapılır ve - bunu elde etmek - belgeleri okuyarak yapılır. Ayrıca, bu iki hizmeti uygularken, gerçek bir şema veya referans belgesi olmadığından borudan ne geleceğine dair "tahminler" yapmanız gerekir.

2) Neden XML döndüren bir REST hizmeti yazıyorsunuz? Tek fark REST ile her öğenin / özniteliğin temsil ettiği türleri bilmemenizdir - onu uygulamak için kendi başınasınız ve bir gün bir dize her zaman bir int olduğunu düşündüğünüz bir alanda gelmediğini umarsınız. SOAP, WSDL kullanarak veri yapısını tanımlar, böylece bu bir beyinsizdir.

3) SOAP ile SOAP Zarfının "ek yükü" olduğuna dair şikayeti duydum. Bu gün ve yaşta, bir avuç bayt için endişelenmemiz gerekiyor mu?

4) REST ile URL'yi tarayıcıya açıp verileri görebileceğiniz iddiasını duydum. Elbette, REST hizmetiniz basit veya hiç kimlik doğrulama kullanıyorsa. Netflix hizmeti, örneğin, isteğinizi bile gönderebilmeniz için bir şeyleri imzalamanızı ve kodlamanızı gerektiren OAuth'u kullanır.

5) Neden her kaynak için "okunabilir" bir URL'ye ihtiyacımız var? Hizmeti uygulamak için bir araç kullanıyor olsaydık, gerçek URL'yi gerçekten önemsiyor muyuz?

Devam etmem gerekiyor mu?

Yazdığım uygulamaların çoğu sunucu tarafı C # veya Java veya WinForms veya WPF'deki masaüstü uygulamalarıdır. Bu uygulamalar, REST'in sağlayabileceğinden daha zengin bir hizmet API'sine ihtiyaç duyma eğilimindedir. Ayrıca, web hizmeti istemcimi oluşturmak için birkaç dakikadan fazla zaman harcamak istemiyorum. WSDL işleme istemcisi oluşturma araçları, istemcimi uygulamama ve işletme değeri katmaya devam etmeme izin veriyor.

Şimdi, bazı javascript ajax çağrıları için açıkça bir web hizmeti yazıyor olsaydım, muhtemelen REST olurdu; sadece müşteri teknolojisini bilmek ve JSON'u kullanmak uğruna. Bence, javascript kullanılan web servis API'leri muhtemelen çok karmaşık olmamalıdır, çünkü bu tür karmaşıklık daha iyi sunucu tarafı ele gibi görünüyor.

Bununla birlikte, javascript için bazı SOAP istemcileri var; JQuery'de bir tane olduğunu biliyorum. Bu nedenle, sabun olabilir JavaScript ile desteklenebilir; JSON dizeleri döndüren bir REST hizmeti kadar güzel değil. Bu nedenle, rasgele sayıda istemci teknolojisi ve kullanımı için esnek olacak kadar karmaşık olmasını istediğim bir web hizmetim olsaydı, SOAP ile giderdim.

Önce REST ile gitmenizi tavsiye ederim - Java kullanıyorsanız JAX-RS ve Jersey uygulamasına bakın. REST birçok dilde birlikte çalışmak çok daha basit ve kolaydır.

Diğerlerinin bu iş parçacığında söylediği gibi, diğer WS- * spesifikasyonları geldiğinde SOAP ile ilgili sorun karmaşıktır ve WSDL, XSD'ler, SOAP, WS-Adresleme vb. Gibi yanlış bölümlere saparsanız sayısız birlikte çalışma sorunu vardır.

REST v SOAP tartışmasını değerlendirmenin en iyi yolu internete bakmaktır - web alanındaki hemen hemen tüm büyük oyuncular, google, amazon, ebay, twitter ve diğerleri - RESTful API'leri SOAP'lara kıyasla kullanma ve tercih etme eğilimindedir.

REST ile devam etmenin diğer güzel yaklaşımı, bir web uygulaması ile REST kullanıcı arabirimi arasında çok sayıda kodu ve altyapıyı yeniden kullanabilmenizdir. JAX-RS ve örtülü görünümler gibi çerçevelerle HTML'nin XML'e karşı XML'in JSON'a dönüştürülmesi normalde oldukça kolaydır - ayrıca bir web tarayıcısı kullanarak RESTful kaynaklarla çalışmak kolaydır

Don Kutusu şaka olarak SOAP oluşturulan eminim - 'bakmak olabilir o web standartları bir şişirilmiş kabusu hale geldiğini fark ettiğinde ve bugün inleyene web üzerinden RPC yöntemleri çağırmak' :-)

REST iyi, basit, her yerde uygulanır (standartlardan daha 'standart' daha fazla) hızlı ve kolaydır. REST kullanın.

Her ikisinin de kendine ait bir yeri olduğunu düşünüyorum. Bence:

SABUN : WS- * 'nin anlamlı olduğu (güvenlik, politika vb.) Temel katmandaki eski / kritik sistemler ile bir web / web hizmet sistemi arasında entegrasyon için daha iyi bir seçim.

RESTful : Katmanın ÜSTÜNDE genel API ile web siteleri arasında entegrasyon için daha iyi bir seçimdir (VIEW, yani URI'lere çağrı yapan javascripts).

Bahsedilmeyen bir şey, bir SOAP zarfının üstbilgilerin yanı sıra gövde bölümlerini de içermesidir. Bu, bant dışı bilgi göndermek ve almak için XML'in tam anlamıyla kullanılmasını sağlar. REST, bildiğim kadarıyla sizi HTTP Üstbilgileri ve sonuç kodlarıyla sınırlandırıyor.

(otoh, bant verileri dışında "başlık" türü göndermek için bir REST hizmetine sahip çerezler kullanabilir misiniz?)

XML-RPC'yi göz ardı etmeyin. Hafif bir çözümden hemen sonraysanız, birkaç sayfa metinde tanımlanabilen ve minimum miktarda kodla uygulanabilen bir protokol için söylenecek çok şey var. XML-RPC yıllardır varlığını sürdürüyor, ancak bir süredir modası geçmiş - ancak minimalist cazibe, geç bir canlanma gibi görünüyor.

2012 yenilenmiş (ikinci ödül) sorusunu cevaplamak ve bugünün sonuçlarını gözden geçirmek (diğer cevaplar).

SABUN, artıları ve eksileri

SOAP 1.2 hakkında, "REST" ile karşılaştırıldığında avantajları ve dezavantajları ... Peki, 2007'den beri REST Web hizmetlerini WSDL ile ve SOAP protokolünü kullanarak tanımlayabilirsiniz ... Yani, biraz daha sıkı çalışırsanız, tüm W3C standartları web hizmetleri protokol yığını REST olabilir !

Bu iyi bir başlangıç ​​noktasıdır, çünkü tüm felsefi ve metodolojik tartışmaların geçici olarak önlendiği bir senaryo hayal edebiliriz. Benzer hizmetlerde teknik olarak "SOAP-REST" ile "SOAP-REST" karşılaştırılabilir,

• SOAP-REST (= "REST-SOAP"): L.Mandel tarafından gösterildiği gibi , WSDL2 bir REST web hizmetini tanımlayabilir ve örneklenen XML'nin SOAP içine alınabileceğini varsayarsak tüm uygulama "SOAP-REST" olacaktır. .

• SOAP-REST : SOAP olamaz herhangi bir REST web hizmeti ... Yani, iyi bilinen REST örneklerinin "% 90" ıdır. Bazıları XML kullanmaz (bunun yerine tipik AJAX REST'ler JSON kullanır), bazıları ise SOAP üstbilgileri veya kuralları olmadan başka bir XML yapısı kullanır. Not: Kayıt dışılığı önlemek için, karşılaştırmalarda REST seviye 2 olduğunu varsayabiliriz .

Tabii ki, daha kavramsal olarak karşılaştırmak için, farklı modelleme yaklaşımları olarak "NON-REST-SOAP" ile "NAP-SOAP-REST" karşılaştırınız. Yani, bu web hizmetleri sınıflandırmasını tamamlamak:

• REST-SOAP : REST olamaz herhangi bir SOAP web hizmeti ... Yani, iyi bilinen SOAP örneklerinin "% 90" ıdır.

• DİNLENMEYEN-NEITHER-SABUN : evet, "web hizmetleri modellemesi" evreni başka şeyleri de içerir (ör. XML-RPC ).

REST koşullarında SOAP

Karşılaştırılabilir şeylerin karşılaştırılması: SOAP-REST ile SOAP-REST .

Artıları

Bazı terimleri açıklamak,

• Sözleşme istikrarı : her türlü sözleşme için ("yazılı sözleşmeler" olarak),

  • By standars kullanımı : tüm seviyeler W3C yığını karşılıklı uyumludur. Diğer yandan REST, bir W3C veya ISO standardı değildir ve hizmet çevre birimleri hakkında normatize ayrıntıları yoktur. Yani, ben , @DaveWoldrich (20 oy), @cynicalman (5), @Exitos (0) daha önce söylediğim gibi, STANDARTLAR İÇİN GEREKLİ olan bir bağlamda, SABUNA ihtiyacınız var.

  • By en iyi uygulamaların kullanımı : bir "Ayrıntılı yönüyle" W3C yığını uygulamaları, ilgili insan / yasal / juridic anlaşmaları çevirir.

• Sağlamlık : SOAP yapısı ve başlıklarının güvenliği. Metada iletişimi (tam XML ifadesi ile) ve doğrulama ile herhangi bir değişikliğe veya gürültüye karşı bir "sigorta poliçeniz" vardır.
  SOAP, "iletişim başarısızlıklarıyla ilgili işlemsel güvenilirlikle (...) ilgilenir. SOAP, yeniden deneme mantığı üzerinde daha fazla kontrole sahiptir ve bu nedenle uçtan uca güvenilirlik ve servis garantileri sağlayabilir", E. Terman .

Profesyonelleri popülerliğe göre sıralamak,

• Daha iyi araçlar (~ 70 oy): SOAP şu anda daha iyi araçlar avantajına sahiptir, çünkü 2007 ve hala 2012, çünkü iyi tanımlanmış ve yaygın olarak kabul gören bir standarttır. Bakınız @MarkCidade (27 oy), @DaveWoldrich (20), @JoshM (13), @TravisHeseman (9).

• Standartlara uygunluk (25 oy): I , @DaveWoldrich (20 oy), @cynicalman (5), @Exitos (0) daha önce söylediğimiz gibi STANDARTLAR İÇİN GEREKLİ olan bir bağlamda, SABUNA ihtiyacınız var.

• Sağlamlık : SOAP başlıklarının sigortası, @JohnSaunders (8 oy).

EKSİLERİ

• SOAP yapılandırması daha karmaşıktır (300'den fazla oy): buradaki tüm cevaplar ve "SOAP vs REST" ile ilgili kaynaklar, SOAP'ın fazlalık ve karmaşıklığı ile bir dereceye kadar hoşnutsuzluk gösterir. Bu, resmi doğrulama (aşağıya bakınız) ve sağlamlık (yukarıya bakınız) gereksinimlerinin doğal bir sonucudur . "SABİT OLMAYAN SABUN" (ve XML-RPC, SOAP oluşturucu ) daha basit ve gayri resmi olabilir.

• "Yalnızca XML" kısıtlaması, küçük hizmetler (~ 50 oy) kullanırken bir performans engelidir : bkz. Json.org/xml ve bu soru veya diğeri . Bu nokta @toluju (41) ve diğerleri tarafından gösterilir.
  Not: JSON bir IETF standardı değildir , ancak web yazılımı topluluğu için fiili bir standart düşünebiliriz .

SOAP ile modelleme hizmetleri

Şimdi, biz ekleyebilir SABUN-OLMAYAN DİNLENME ile OLMAYAN SABUN-DİNLENME karşılaştırmalar ve açıklamak kullanım SOAP iyi olduğunda :

• Standartlara ve istikrarlı sözleşmelere duyulan ihtiyaç (bkz. "PROS" bölümü). Not: @saille tarafından açıklanan tipik bir "standartlar için B2B gereksinimi" ne bakın .

• Alet ihtiyacı (bkz. "PROS" bölümü). Not: standartlar ve resmi doğrulamaların varlığı (aşağıya bakınız), araç otomasyonu için önemli konulardır.

• Paralel ağır işleme (aşağıdaki "Bağlam / Vakıflar" bölümüne bakın): daha büyük ve / veya daha yavaş süreçlerle, biraz daha karmaşık SOAP karmaşıklığı ne olursa olsun, güvenilirlik ve istikrar en iyi yatırımlardır.

• Daha fazla güvenliğe ihtiyacınız var : HTTPS'den daha fazlası gerektiğinde ve gerçekten koruma için ek özelliklere ihtiyacınız olduğunda, SOAP daha iyi bir seçimdir ( bkz. @Bell , 32 oy). "İletiyi istek / yanıttan daha karmaşık bir yol boyunca veya HTTP içermeyen bir aktarım üzerinden gönderme", S. Seely . XML, XML Şifrelemesi , XML İmzası ve XML Kanonikleştirmesi için standartlar sunan temel bir sorundur ve yalnızca SOAP ile bu mekanizmaları WS-Security olarak kabul edilmiş bir standartta bir iletiye gömebilirsiniz .

• Daha fazla esnekliğe ihtiyacınız var (daha az kısıtlama): SOAP, bir URI ile tam yazışma gerektirmez; nedd HTTP ile sınırlı değil; 4 fiil ile sınırlandırılmasına gerek yoktur. @TravisHeseman'ın (9 oy) dediği gibi, "gelişigüzel sayıda istemci teknolojisi ve kullanımı için esnek" bir şey istiyorsanız, SOAP kullanın.
  PS: XML'nin JSON (ve ark.) 'Dan daha evrensel / anlamlı olduğunu unutmayın.

• Resmi doğrulama ihtiyacı : W3C yığının resmi yöntemler kullandığını ve REST'in daha resmi olmadığını anlamak önemlidir . WSDL ( biçimsel dil ) hizmet açıklamanız, web hizmetleri arabirimlerinizin resmi bir özelliğidir ve SOAP, olası tüm WSDL reçetelerini kabul eden sağlam bir protokoldür.

BAĞLAM

Tarihi

Eğilimleri değerlendirmek için tarihsel perspektif gereklidir. Bu konu için 10 veya 15 yıllık bir bakış açısı ...

W3C standardizasyonundan önce bazı anarşi vardır. Farklı çerçevelerle birlikte çalışabilir hizmetler uygulamak zordu ve şirketler arasında birlikte çalışabilir bir şey uygulamak için daha zor, maliyetli ve zaman alıcıydı. W3C yığını standartları hafif, karmaşık web hizmetlerinin setlerinin karşılıklı operasyon için bir kuzey olmuştur.

AJAX uygulamak gibi günlük görevler için, SOAP ağırdır ... Yani, basit yaklaşımlara ihtiyaç yeni bir teori çerçevesi seçmek gerekir ... Ve Google, Amazon gibi büyük "Web yazılım oyuncuları", Yahoo ve arkadaşları, en iyi alternatif olan REST yaklaşımı seçtiler. Bu bağlamda REST kavramı bir "rakip çerçeve" olarak geldi ve bugün (2012'ler), bu alternatif programcılar için fiili bir standarttır .

temeller

Paralel Hesaplama bağlamında , web hizmetleri paralel alt görevler sağlar; ve SOAP gibi protokoller iyi senkronizasyon ve iletişim sağlar. "Herhangi bir görev" değil: web hizmetleri
kaba ve utanç verici paralellik olarak sınıflandırılabilir .

Görev büyüdükçe, daha az önemli "karmaşıklık tartışması" haline gelir ve iletişimin sağlamlığı ve sözleşmelerin sağlamlığı daha önemli hale gelir.

Nüanslı.

Hizmetlerinizle başka sistemlerin arayüzüne ihtiyacınız varsa, sözleşmeler, WSDL ve SOAP standardı ile sahip olduğunuz "doğrulama" katmanları nedeniyle SOAP ile çok daha fazla müşteri daha mutlu olacaktır.

Sistemlere çağrı yapan günlük sistemler için, basit bir HTML çağrısı yapıldığında SOAP'ın gereksiz bir ek yük olduğunu düşünüyorum.

Aynı şekilde bakıyorum ve bence farklı problemler için farklı araçlar .

Basit Nesne Erişim Protokolü (SOAP) standardı, bir mesaj mimarisini ve mesaj formatlarını tanımlayan bir XML dili olup, işlemlerin bir açıklamasını içeren Web servisleri tarafından kullanılır. WSDL, Web hizmetlerini ve bunlara nasıl erişileceğini açıklayan XML tabanlı bir dildir. SMTP, HTTP, FTP vb.

Temsili Durum Transferi (RESTful) web hizmetleri. bunlar ikinci nesil Web Servisleridir. RESTful web hizmetleri, HTTP üzerinden SOAP tabanlı hizmetlerden daha fazla iletişim kurun ve XML mesajları veya WSDL hizmet-API tanımları gerektirmez. REST için hiçbir ara katman yazılımı gerekmez sadece HTTP desteği gereklidir. WADL Standardı, REST XML, düz metin, JSON, HTML vb.

Sunucu tarafının gelişmesini ve ölçeklenmesini sağlarken birçok istemci türünün RESTful web hizmetlerini kullanması daha kolaydır. Müşteriler, hizmetin bazı veya tüm yönlerini tüketmeyi ve diğer web tabanlı hizmetlerle birleştirmeyi seçebilir.

1. REST standart HTTP kullanır, bu nedenle istemci oluşturmak, API geliştirmek daha kolaydır
2. REST, XML, düz metin, JSON, HTML gibi birçok farklı veri formatına izin verir, burada SOAP yalnızca XML'e izin verir.
3. REST daha iyi performans ve ölçeklenebilirliğe sahiptir.
4. Dinlenin ve önbelleğe alınabilir ve SOAP olamaz
5. SOAP'ın olmadığı yerleşik hata işleme Hata işleme yok
6. REST özellikle yararlı PDA ve diğer mobil cihazlardır.

REST, hizmetlerin mevcut web siteleriyle entegre edilmesi kolaydır.

SOAP, güvenlik ve güvenilirlik için standartlar sağlayan ve diğer WS uyumlu istemciler ve sunucularla birlikte çalışan protokoller kümesine sahiptir. SOAP Web servisleri (JAX-WS gibi), eşzamansız işleme ve çağırma işlemlerinde faydalıdır.

Karmaşık API için SOAP daha yararlı olacaktır.

REST, Roy Fielding tarafından icat edilen ve tezi Mimari Stilleri ve Ağ Tabanlı Yazılım Mimarilerinin Tasarımı bölümünde anlatılan bir mimaridir . Roy, HTTP'nin ana yazarıdır - World Wide Web üzerinden belge aktarımını tanımlayan protokol. HTTP RESTful bir protokoldür. Geliştiriciler "REST Web servislerini kullanma" hakkında konuştuğunda, "HTTP kullanma" demek daha doğru olur.

SOAP, bir HTTP isteği / yanıtı içinde tünel oluşturan XML tabanlı bir protokoldür, bu nedenle SOAP kullansanız bile REST kullanıyorsunuzdur. SOAP'ın temel HTTP'ye önemli bir işlevsellik ekleyip eklemediği konusunda bazı tartışmalar vardır.

Bir Web hizmetini yazmadan önce HTTP çalışmanızı tavsiye ederim. Oranlar, gereksinimlerinizde önceden tanımlanmış işlevlerle uygulanabileceğinden, diğer protokollere gerek kalmayacaktır.

Aynı konuya bakıyorum. Bana göre aslında REST hızlı ve kolay ve hafif aramalar ve yanıtlar için iyi ve hata ayıklama için harika (bir URL'yi bir tarayıcıya pompalamak ve yanıtı görmek daha iyi olabilir).

Ancak REST düşmek gibi görünüyor onun standart değil (standartlardan oluşmasına rağmen) gerçeği ile ilgilidir. Çoğu programlama kütüphanesi, bir SOAP tabanlı hizmetleri tüketmek için gereken istemci kodunu otomatik olarak oluşturmak için bir WSDL'yi inceleme yoluna sahiptir. Bu yüzden çok tüketen REST tabanlı web hizmetleri, mümkün olan çağrıları eşleştirmek için bir arayüz yazma konusunda daha adhoc bir yaklaşım gibi görünüyor. Manuel bir http isteği yapmak ve ardından yanıtı çözümlemek. Bu kendi başına tehlikeli olabilir.

SOAP'ın güzelliği, bir WSDL yayınlandıktan sonra işin 'arabirimdeki herhangi bir değişikliğin wsdl'yi değiştireceği sözleşmeyi ayarlayan mantık aorundunu yapılandırabilmesidir. Manevra için yer yoktur. Bu WSDL'ye karşı tüm istekleri doğrulayabilirsiniz. Ancak bir WSDL bir REST hizmetini doğru bir şekilde tanımlayamadığından, iletişim arabirimini kabul etmenin tanımlanmış bir yolu yoktur.

Bir iş perspektifinden bakıldığında bu, iletişimi yorumlamaya ve değişime açık bırakıyor gibi görünüyor ki bu kötü bir fikir gibi görünüyor.

Bu konudaki üstteki 'Cevap', SOAP'ın Basit Nesne Odaklı Erişim Protokolü anlamına geldiğini, ancak wiki'ye bakıldığında O'nun Nesne Odaklı Olmayan Nesne anlamına geldiğini söylüyor. Bunlar farklı şeyler.

Bu yazının çok eski olduğunu biliyorum ama kendi bulgularıma cevap vermem gerektiğini düşündüm.

Bu iyi bir soru ... Seni yoldan çıkarmak istemiyorum, bu yüzden senin kadar başkalarının cevaplarına da açığım. Benim için, bu, genel masraf ve API kullanımının maliyetine bağlıdır. İstemci yazılımı oluştururken web hizmetlerini tüketmeyi tercih ediyorum, ancak SOAP'ın ağırlığını sevmiyorum. REST, inanıyorum ki, daha hafiftir, ancak onunla neredeyse bir müşteri perspektifinden çalışmaktan hoşlanmıyorum.

Başkalarının ne düşündüğünü merak ediyorum.

Öğrenmek için bu podcast'i dinleyin . Cevabı dinlemeden bilmek istiyorsanız, OK, onun REST. Ama gerçekten dinlemenizi tavsiye ederim.

Genel kuralım, bir tarayıcı web istemcisinin doğrudan bir hizmete bağlanmasını istiyorsanız, muhtemelen REST kullanmanız gerekir. Yapılandırılmış verileri arka uç hizmetleri arasında iletmek istiyorsanız, SOAP kullanın.

SOAP bazen kurmak için gerçek bir acı olabilir ve basit web istemcisi ve sunucu veri alışverişi için genellikle aşırıya kaçar. Ne yazık ki, gördüğüm (ve öğrendiğim) en basit programlama örnekleri bu algıyı biraz güçlendirdi.

Bununla birlikte, bir veri iş akışı tarafından yönetilen daha büyük bir sürecin bir parçası olarak birden çok SOAP hizmetini bir araya getirmeye başladığınızda SOAP gerçekten parlıyor (kurumsal yazılımı düşünün). Bu, SOAP programlama örneklerinin çoğunun iletemediği bir şeydir, çünkü bir hisse senedinin fiyatını getirme gibi bir şey yapmak için basit bir SOAP işlemi, bir makine sağlama bağlamında sunulmadıkça genellikle kendi başına yaptığı şey için aşırı karmaşıktır. girişler ve çıkışlar için belirlenmiş veri formatlarıyla belirli işlevleri detaylandıran okunabilir API, daha büyük bir işlem tarafından komut dosyası olarak yazılır.

Bu bir anlamda üzücüdür, çünkü SOAP'a gerçekten kötü bir ün kazandırır çünkü SOAP'ın avantajlarını nihai ürünün nasıl kullanıldığının tam bağlamında sunmadan göstermek zordur.

SOAP , hizmetlerle birincil etkileşim yöntemlerin (veya fiillerin) olduğu Web hizmetlerine hizmet odaklı bir yaklaşım içerir. REST , nesnenin (ya da ismin) merkez sahne aldığı kaynak odaklı bir yaklaşım benimser.

"PHP-evren" anlamında herhangi bir gelişmiş SOAP için PHP desteği büyük zaman berbat. WS-Security veya WS-RM dahili desteğini etkinleştirmemek için bile temel ihtiyaçları geçtiğinizde http://wso2.com/products/web-services-framework/php/ gibi bir şey kullanacaksınız .

SOAP zarf oluşturma Ben PHP, çok ad alanları oluşturma biçiminde dağınık olduğunu hissediyorum, xsd: nil, xsd: anytype ve SOAP Kodlama (Tanrı bu nasıl farklı olduğunu bilir) kullanan SOAP mesajlarda Hizmetleri.

REST'e bağlı kalarak tüm bu karmaşadan kaçının, REST, WWW'nin başlangıcından beri kullandığımız gerçekten büyük bir şey değil. Yalnızca bu http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm belgesi çıktığında RESTFul Hizmetlerini uygulamak için HTTP özelliklerini nasıl kullanabileceğimizi gösterdik. HTTP doğal olarak REST'tir, bu sadece HTTP kullanmak hizmetlerinizi RESTFul yapar anlamına gelmez.

SOAP, HTTP'nin temel özelliklerini ihmal eder ve HTTP'yi bir aktarım protokolü olarak kabul eder, bu nedenle teoride aktarım protokolüdür (pratikte, şimdi google değilse, SOAP Eylem başlığını duymuşsunuzdur!).

JSON uyarlaması artıyor ve javascript olgunlaşması ile HTML5 ile JSON ile REST, hizmetlerle uğraşmanın en yaygın yolu haline geldi. JSON Şeması ayrıca gerektiğinde WADL ile birlikte kurumsal düzeyde çözümler (hala erken aşamalarda) için de tanımlanabilir.

REST ve JSON için PHP desteği, mevcut dahili SOAP desteğinden kesinlikle daha iyidir.

Buraya birkaç BUZZ kelime daha ekleyerek SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

Bu arada özellikle WS-Security özellikleri için SOAP'ı seviyorum, bu iyi bir spesifikasyon ve Enterprise JSON uyarlamasında düşünen birisinin kesinlikle alan düzeyinde şifreleme gibi JSON için benzer bir şeyle gelmesi gerekiyorsa.

Bir hızlı nokta - iletim protokolü ve düzenleme;

TCP üzerinden SOAP'ı, makine hizmetlerine (ESB) ve dış hizmetlere yönelik orkestre makine de dahil olmak üzere hız, güvenilirlik ve güvenlik nedenleriyle kullanıyorum. Hizmet tanımını değiştirin, düzenleme WSDL değişikliğinden ve derhal açık olan bir hatayla karşılaşır ve yeniden oluşturulabilir / dağıtılabilir.

Aynı şeyi REST ile yapabileceğinizden emin değilim - düzeltilmeyi veya rotayı bekliyorum! REST ile hizmet tanımını değiştirin - 400 (veya her neyse) döndürülene kadar hiçbir şey bilmez.

Farklı sistemler ve diller arasında birlikte çalışabilirlik arıyorsanız, kesinlikle REST için gitmek istiyorum. Örneğin, .NET ve Java arasında SOAP'ı çalıştırmaya çalışırken çok fazla sorun yaşadım.

Hangisinin daha hızlı olduğunu bulmak için bir kıyaslama oluşturuyorum! bu sonucu görüyorum:

1000 istek için:

• REST 3 saniye sürdü
• SOAP 7 saniye sürdü

10.000 istek için:

• REST 33 saniye sürdü
• SOAP 69 saniye sürdü

1.000.000 istek için:

• REST 62 saniye sürdü
• SOAP 114 saniye sürdü

Eski bir soru ama bugün hala geçerli .... kurumsal alanda pek çok geliştirici nedeniyle hala kullanıyor.

Çalışmam IoT (Nesnelerin İnterneti) çözümlerini tasarlamayı ve geliştirmeyi içeriyor. Bu, Bulut ile iletişim kuran küçük yerleşik aygıtlar için kod geliştirmeyi içerir.

REST'in artık yaygın olarak kabul gördüğü ve yararlı olduğu açıktır ve Microsoft'un Azure genelinde REST desteğine sahip olduğu için web için neredeyse standarttır. SOAP'a güvenmem gerekirse, küçük gömülü cihazlar için çok büyük, hantal ve can sıkıcı olduğu gibi yapmam gereken şeyi yapamadım.

REST basit, temiz ve küçüktür. Küçük gömülü cihazlar için idealdir. Bana bir WSDL gönderen bir web geliştiricisiyle çalışırken çığlık atıyorum. Bunun neden işe yaramayacağı ve neden REST öğrenmek zorunda kalacağı konusunda bir eğitim kampanyası başlatmak zorunda kalacağım.

1. deneyimlerimden. REST'in zaten oluşturulmuş URL'ye erişme seçeneği sunduğunu söyleyebilirim. eg-> Google'da kelime arama. Bu URL, REST için web hizmeti olarak kullanılabilir. SOAP'ta kendi web hizmetinizi oluşturabilir ve SOAP istemcisi aracılığıyla bu hizmete erişebilirsiniz.

2. REST, metin, JSON, XML biçimini destekler. Bu nedenle iki uygulama arasında iletişim kurmak için çok yönlüdür. SOAP mesaj iletişimi için sadece XML formatını destekler.