it-swarm-tr.com

Web Servisleri için SOAP ya da REST?

REST Web Hizmetleri yapmak için daha iyi bir yaklaşım mı yoksa SOAP mı? Yoksa farklı problemler için farklı araçlar mı? Yoksa nüanslı bir mesele mi - yani, belirli arenalarda biri diğerinden biraz daha mı iyi?

Özellikle bu kavramlar ve bunların PHP-evreni ve ayrıca modern ileri teknoloji web uygulamaları ile olan ilişkileri hakkındaki bilgileri takdir ediyorum.

380
user13276

Hewlett-Packard'da çalışırken, kod oluşturma ve WSDL oluşturma dahil ilk SOAP sunucuyu, geliştirilmekte olan orijinal spesifikasyondan oluşturdum. Hiçbir şey için SOAP kullanmanızı önermiyorum.

"SOAP" kısaltması bir yalandır. Basit değildir, Nesne yönelimli değildir, Erişim kuralları tanımlamaz. Muhtemelen bir Protokol'dür. Bu Don Box'ın şimdiye kadarki en kötü özelliği ve "COM" u yapan kişi olduğu için bu oldukça büyük bir başarı.

SOAP öğesinde aktarım için REST ve JSON, XML ve hatta veri gösterimi için düz metinle yapılamayan hiçbir şey yoktur. Taşıma güvenliği için https kullanabilirsiniz. Kimlik doğrulaması için temel kimlik doğrulaması. Seanslar için çerezler var. REST sürümü daha basit, daha net, daha hızlı çalışacak ve daha az bant genişliği kullanacaktır.

XML-RPC, talebi, 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.

562
mdhughes

REST bir mimaridir, SOAP bir protokoldür.

Bu ilk problem.

SOAP uygulamasında REST zarf gönderebilirsiniz.

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

Tüketicileriniz başka uygulamalar ve diğer sunucular ise, bugün SOAP protokolü için çok fazla destek var ve hareketli verilerin temelleri temelde modern IDE'lerde bir fare tıklaması.

Tüketicilerinizin RIA'lar veya Ajax müşterileri olma ihtimalleri daha yüksekse, muhtemelen SOAP'tan daha basit ve istemciye özgü bir şey (özellikle JSON) isteyeceksiniz.

HTTP üzerinden gönderilen JSON paketleri mutlaka bir REST mimarisi değildir, yalnızca URL’lere mesaj gönderir. Hepsi mükemmel şekilde uygulanabilir, ancak REST deyiminin kilit bileşenleri vardır. Ancak ikisini karıştırmak kolaydır. Ancak, HTTP isteklerinden bahsettiğiniz için mutlaka bir REST mimarisine sahip olduğunuz anlamına gelmez. HTTP içermeyen bir REST uygulamasına sahip olabilirsiniz (zihin, bu nadirdir).

Öyleyse, SOAP ile "rahat" olan sunucularınız ve tüketicileriniz varsa, SOAP ve WSS yığını size iyi hizmet edebilir. Daha fazla geçici iş yapıyorsanız ve web tarayıcılarıyla daha iyi bir arayüz oluşturmak istiyorsanız, HTTP üzerinden daha hafif bir protokol de işe yarayabilir.

198
Will Hartung

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

Eğer okuyacak vaktiniz yoksa, işte kısa versiyon: REST "isimler" e odaklanarak ve bunlara uygulayabileceğiniz "fiil" sayısını kısıtlayarak bir paradigma kayması biraz. isimler. İzin verilen tek fiiller "get", "put", "post" ve "delete" dir. Bu, farklı adlara birçok farklı fiilin uygulanabileceği SOAP değerinden farklıdır (yani birçok farklı fonksiyon).

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

Bunların çoğu ortadan kalsa da pratikte ve REST genellikle sadece JSON sonuçlarını döndüren basit HTTP isteklerini ifade eder. SOAP, XML'i geçirerek iletişim kuran daha karmaşık bir API'dir. Her ikisinin de avantajları ve dezavantajları var, ancak deneyimlerime göre REST genellikle daha iyi bir seçimdir, çünkü nadiren SOAP'tan tam bir işlevselliğe ihtiyacınız olursa, çok nadiren ihtiyacınız olur.

102
toluju

2012 sorusu için hızlı aşağı indirme:

REST için gerçekten iyi çalışan alanlar:

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

  • Tamamen vatansız işlemler. Bir işlemin devam etmesi gerekiyorsa, REST en iyi yaklaşım değildir ve SOAP daha uygun olabilir. Ancak, durumsuz CRUD (Oluştur, Oku, Güncelle ve Sil) işlemlerine ihtiyacınız varsa, REST budur.

  • Önbelleğe alma durumları. REST yaklaşımının tamamen vatansız çalışması nedeniyle bilgi önbelleğe alınabilirse, bu mükemmeldir. Yukarıdaki üçte birçok çözüm var.

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

  • Eşzamansız işleme ve başlatma. Uygulamanızın garantili bir güvenilirlik ve güvenlik düzeyine ihtiyacı varsa, SOAP 1.2 bu türden emin olmak için ek standartlar sunar. işlem WSRM gibi şeyler - WS-Güvenilir Mesajlaşma.

  • Resmi sözleşmeler Eğer iki tarafın (sağlayıcı ve tüketici) değişim formatı üzerinde anlaşması gerekiyorsa, o zaman SOAP 1.2, bu tür bir etkileşim.

  • Durumlu işlemler. Uygulama içeriğe dayalı bilgi ve konuşma durumu yönetimine ihtiyaç duyuyorsa, SOAP 1.2, WS * yapısında belirtilen ek özelliklere sahiptir. bunları destekleyin (Güvenlik, İşlemler, Koordinasyon, vb.). Nispeten, REST yaklaşımı, geliştiricilerin bu özel sıhhi tesisat yapmasını sağlayacaktır.

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

59
PmanAce

SOAP şu anda hem servis katmanı için hem de verilen herhangi bir WSDL'den müşteri üretme için çok sayıda kazan plakası kodu üretecekleri daha iyi araçlar avantajına sahiptir.

REST daha basittir, sonuç olarak bakımı daha kolay olabilir, Web mimarisinin merkezinde yer alır, daha iyi protokol görünürlüğü sağlar ve WWW'nin boyutunda ölçeklendirildiği kanıtlanmıştır. Dışarıdaki bazı çerçeveler, Rails'te REST gibi Ruby hizmetleri oluşturmanıza ve hatta ADO.NET Veri Hizmetleri gibi müşterileri yazmanıza bile yardımcı oluyor. Ancak çoğunlukla, araç desteği eksiktir.

44
Mark Cidade

SOAP takım perspektifinden kullanışlıdır, çünkü WSDL araçlar tarafından kolayca tüketilir. Böylece, sizin için Web Hizmeti istemcilerini en sevdiğiniz dilde oluşturabilirsiniz.

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

REST, daha iyi performans gösterme eğilimindedir. REST yanıtı veren kodun CPU gereksinimleri, SOAP çerçevelerinin gösterdiğinden daha düşük olma eğilimindedir. XML oluşturma ördeklerinizi sunucu tarafında sıraya dizdiyseniz, XML'i etkin bir şekilde istemciye aktarabilirsiniz. Yani, veritabanı imlecinin satırlarını okuduğunuzu hayal edin. Bir satırı okurken, onu bir XML öğesi olarak biçimlendirirsiniz ve bunu doğrudan servis tüketicisine yazarsınız. Bu şekilde, XML çıktınızı yazmaya başlamadan önce tüm veritabanı satırlarını bellekte toplamak zorunda değilsiniz - aynı anda okuyup yazıyorsunuz. Akışın REST'te çalışmasını sağlamak için yeni şablonlama motorlarına veya XSLT'ye bakın.

SOAP ise araç tarafından üretilen servisler tarafından büyük bir blok olarak üretilip daha sonra yazıldı. Bu mutlak bir gerçek değil, aklınızda bulundurun, ekleri kullanmak gibi SOAP'tan akış özelliklerini elde etmenin yolları vardır.

Karar verme sürecim şu şekildedir: hizmetimin tüketiciler tarafından kolayca uygulanmasını istiyorsam ve yazdığım mesajlar orta ila küçük ölçekli (10 MB veya daha az) olacak ve biraz daha fazla CPU yakma sakıncası yoksa sunucuda döngüleri, SOAP ile giderim. Web tarayıcılarında AJAX hizmet vermem gerekiyorsa veya yayınlayacağım şeye ihtiyacım olursa veya yanıtlarım çok büyükse, REST’e giderim.

Son olarak, SOAP çevresinde oluşturulmuş, WS-Security ve doğru araçları kullanıyorsanız bağlanabileceğiniz durumsal Web Servisleri gibi birçok büyük standart var. Bu tür şeyler gerçekten bir fark yaratıyor ve bazı kıllı gereklilikleri yerine getirmenize yardımcı olabilir.

40
Dave Woldrich

Bunun eski bir soru olduğunu biliyorum ama cevabımı göndermem gerekiyor - belki birileri bunu faydalı bulabilir. SOAP üzerinden kaç kişinin REST tarafından tavsiye edildiğine inanamıyorum. Bu insanların yalnızca geliştirici olmadıklarını veya herhangi bir makul boyutta REST hizmetini uygulamadıklarını varsayabilirim. REST hizmetinin uygulanması, SOAP hizmetinin uygulanmasından çok daha uzun sürüyor. Ve sonunda da çok daha karışık oluyor. İşte seçtiğim sebepler: SOAP Zamanın% 99’u:

1) 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 bulunur. REST hizmetinin uygulanması el ile yapılır ve - bunu elde edin - belgeleri okuyarak. Ayrıca, bu iki hizmeti uygularken, gerçek bir şema veya referans belgesi olmadığından borudan ne çıkacağına dair "tahminler" yapmanız gerekir.

2) Neden yine de XML döndüren bir REST hizmeti yazmalı? Tek fark, REST ile her bir elemanın/niteliğin temsil ettiği türlerini bilmiyor olmanızdır - onu uygulamak için tek başınıza kalırsınız ve bir gün bir dizginin bir alanda karşınıza çıkmadığını umarsınız. düşünce her zaman bir int idi. SOAP, WSDL kullanarak veri yapısını tanımlar, bu nedenle bu bir uzman değil.

3) SOAP ile SOAP Zarfın "ek yüküne" sahip olduğunuz şikayetini 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ğinize dair argümanı duydum. Tabii, REST hizmetiniz basit veya hiç kimlik doğrulama kullanıyorsa. Örneğin Netflix hizmeti, isteğinizi göndermeden önce bir şeyleri imzalamanızı ve kodlamanızı gerektiren OAuth öğesini kullanır.

5) Her kaynak için neden "okunabilir" bir URL'ye ihtiyacımız var? Hizmeti uygulamak için bir araç kullanıyor olsaydık, gerçek URL’yi gerçekten önemser miyiz?

Devam edeyim mi

29
Josh M.

Yazdığım uygulamaların çoğu, sunucu tarafı C # veya Java veya WinForms veya WPF'deki masaüstü uygulamalarıdır. Bu uygulamalar REST'ın sağlayabileceğinden daha zengin bir servis API'sine ihtiyaç duyuyor. Ayrıca, web servis istemcimi oluşturmak için birkaç dakikadan fazla harcamak istemiyorum. WSDL işleme istemcisi oluşturma araçları, istemcimi uygulamama ve işletme değeri eklemeye devam etmemi sağlıyor.

Şimdi, bazı javascript ajax çağrıları için açıkça bir web servisi yazıyor olsaydım, muhtemelen REST'te olurdu; sadece müşteri teknolojisini bilmek ve JSON'dan yararlanmak için. Bence, javascript'ten kullanılan web servisi API'leri muhtemelen çok karmaşık olmamalı, çünkü bu tür bir karmaşıklık sunucu tarafında daha iyi ele alındığı görülüyor.

Bununla birlikte, javascript için bazı SOAP istemcisi var; JQuery'nin bir tane olduğunu biliyorum. Böylece, SOAP yapabilmek javascript'ten yararlanılması; JSON dizgelerini döndüren bir REST hizmeti kadar güzel değil. Dolayısıyla, rastgele sayıda müşteri teknolojisi ve kullanımı için esnek olmasını sağlayacak kadar karmaşık olmak istediğim bir web hizmetim olsaydı, SOAP ile giderdim.

19
Travis Heseman

İlk önce REST ile gitmenizi tavsiye ederim - eğer Java kullanıyorsanız JAX-RS ve Jersey uygulamasına bakın. REST birçok dilde birlikte çalışmak için çok daha basit ve kolaydır.

Diğerlerinin bu başlıkta söylediği gibi, SOAP ile ilgili sorun, diğer WS- * özellikleri girdiğinde ve WSDL, XSD’lerin, SOAP’ın yanlış kısımlarına saparsanız sayısız birlikte çalışabilirlik sorunu olduğunda karmaşıklığıdır. WS-Adresleme vb.

REST v SOAP tartışmasını yargılamanın en iyi yolu internete bakmaktır - hemen hemen web alanındaki büyük oyuncular, google, Amazon, ebay, Twitter ve diğerleri - RESTful API'leri SOAP olanlar yerine kullanmak ve tercih etmek için.

REST ile devam etmenin diğer güzel yaklaşımı, bir web uygulaması ile bir REST ön ucu arasında birçok kodu ve altyapısını yeniden kullanabilmenizdir. Örneğin. Kaynaklarınızı JSON'a karşı HTML'ye karşı XML oluşturmak, JAX-RS ve örtülü görünümler gibi çerçevelerle normalde oldukça kolaydır - ayrıca bir web tarayıcısı kullanarak RESTful kaynaklarla çalışmak kolaydır

17
James Strachan

Don Box'ın şaka olarak SOAP 'ı yarattığından eminim -' bakalım can web üzerinden RPC yöntemlerini çağırın 've bugün web standartlarının şişirilmiş bir kabusu olduğunu fark ettiğinde bile inliyor olmuş :-)

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

16
gbjbaanb

Sanırım ikisinin de kendine ait bir yeri var. Bence:

SOAP: Eski sistemler/kritik sistemler ve web/web servis sistemi arasındaki entegrasyon için, WS- * 'nin anlamlı olduğu (güvenlik, politika vb.) temel katmanında daha iyi bir seçim.

RESTful: Katmanların tepesinde, genel API ile web siteleri arasında entegrasyon için daha iyi bir seçim (VIEW, yani URI'lere çağrı yapan javascripti).

15
irobson

Bahsedilmemiş olan bir şey, bir SOAP zarfın vücut kısımlarının yanı sıra başlıkları da içerebilmesidir. Bu, bant dışı bilgileri göndermek ve almak için XML'in tam ifadesini kullanmanızı sağlar. REST bildiğim kadarıyla sizi HTTP Başlıkları ve sonuç kodlarıyla sınırlandırıyor.

(otoh, bant verisi dışında "başlık" tipi göndermek için REST hizmetini içeren çerezleri kullanabilir misiniz?)

13
John Saunders

XML-RPC'yi gözden kaçırmayın. Hafif bir çözümün hemen ardındanysanı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 buralardaydı ancak bir süredir modası geçmedi - ancak minimalist çekiciliği ona geç bir canlanma gibi bir şey veriyor gibi görünüyor.

10
Cruachan

Nüanslı.

Servislerinizle başka sistemlerin arayüzüne ihtiyacınız varsa, sözleşmeleriniz, WSDL ve SOAP standardındaki "doğrulama" katmanları nedeniyle, pek çok müşteri SOAP ile daha mutlu olacaktır.

Gündelik sistemlere çağrı yapan sistemler için, basit bir HTML çağrısının yapılacağı zaman SOAP 'ın gereksiz bir yük olduğunu düşünüyorum.

9
cynicalman

REST, Roy Fielding tarafından icat edilmiş ve tezinde açıklanan bir mimaridir Mimari Stiller ve Ağ Tabanlı Yazılım Mimarilerinin Tasarımı . Roy aynı zamanda HTTP - World Wide Web üzerinden belge transferini tanımlayan protokolün ana yazarıdır. HTTP bir RESTful protokolüdür. Geliştiriciler "REST Web hizmetlerini kullanma" hakkında konuştuğunda "HTTP kullanarak" 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 kullanıyor olsanız bile, siz de REST kullanıyorsunuz. SOAP'ın temel HTTP'ye önemli bir işlevsellik katıp katmadığı konusunda bazı tartışmalar var.

Bir Web servisi yazmadan önce, HTTP çalışmasını tavsiye ederim. Muhtemel şartlar, şartnamede önceden tanımlanmış olan fonksiyonelliklerle yerine getirilebilir, bu nedenle başka protokollere ihtiyaç duyulmaz.

8
Chris Broski

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

Bununla birlikte, REST düşme gibi görünüyorsa, standart değil (standart olmasına rağmen) standart değildir. Çoğu programlama kütüphanesi, SOAP tabanlı hizmetleri kullanmak için gereken müşteri kodunu otomatik olarak oluşturmak için bir WSDL'yi denetleme yöntemine sahiptir. Şimdiye kadar REST tabanlı web servisleri tüketmek, mümkün olan aramalarla eşleşmesi için bir arayüz yazmanın daha geçici bir yaklaşım gibi görünüyor. Bir manuel http isteği yapıp cevabı ayrıştırma. Bu kendi içinde tehlikeli olabilir.

SOAP 'ın güzelliği, bir WSDL yayınlandıktan sonra işletme' arayüzünü değiştirmek için kendi mantık alanlarını yapılandırabilecekler. Manevra için yer yok. Tüm istekleri bu WSDL'ye göre doğrulayabilirsiniz. Bununla birlikte, bir WSDL bir REST hizmetini doğru bir şekilde tanımlamadığından, iletişim için arayüz üzerinde anlaşmaya varmadığınız herhangi bir şekilde tanımlanmaz.

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

Bu konudaki en üstteki 'Cevap', SOAP, Basit Nesne Yönelimli Erişim Protokolü anlamına gelir, ancak wiki bakıldığında O, Nesne Yönelimli Değil Nesne anlamına gelir. Onlar farklı şeyler.

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

7
Exitos

Bu iyi bir soru ... Sizi yoldan saptırmak istemiyorum, bu yüzden sizin kadar diğer insanların cevaplarına açığım. Benim için, gerçekten genel giderlerin maliyeti ve API kullanımının ne olduğu geliyor. İstemci yazılımı oluştururken web hizmetlerini tüketmeyi tercih ediyorum, ancak SOAP'ın ağırlığını sevmiyorum. REST, daha hafif olduğuna inanıyorum, ancak müşteri perspektifinden onunla çalışmaktan pek zevk almıyorum.

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

6
cranley

Dinle bu podcast öğrenmek için. Cevabını dinlemeden bilmek istiyorsan, Tamam, REST. Ama gerçekten dinlemeyi tavsiye ediyorum.

6
Mark Beckwith

Genel kural, bir tarayıcı web istemcisinin bir servise doğrudan bağlanmasını istiyorsanız, muhtemelen REST kullanmanız gerektiğidir. Yapısal verileri arka uç servisler arasında iletmek istiyorsanız, SOAP kullanın.

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

Bununla birlikte, SOAP, bir veri iş akışı tarafından yönetilen daha büyük bir sürecin parçası olarak birden fazla SOAP hizmetini bir araya getirmeye başladığınızda gerçekten de parlar (düşünen kurumsal yazılım). Bu, SOAP programlama örneğinin çoğunun iletemediği bir şeydir, çünkü basit bir SOAP işlem yapmak, bir hisse senedinin fiyatını almak gibi bir şey yapmak için genellikle ne tarafından yapıldığını karmaşıklaştırır. Girdi ve çıktılar için ayarlanmış veri formatları ile belirli fonksiyonların detaylandırıldığı, daha büyük bir işlem tarafından kodlanan bir makinede okunabilir API sağlama bağlamında sunulmadığı sürece kendisi.

Bu üzücü, bir anlamda, SOAP 'a kötü bir üne sahip olduğu için, çünkü nihai ürünün nasıl olduğunu tam olarak sunmadan SOAP' ın avantajlarını göstermek zordur. kullanıldı.

6
Rick Sarvas

"PHP-universe" PHP ile herhangi bir gelişmiş SOAP için destek büyük bir zaman emiyor. WS-Security veya WS- özelliğini etkinleştirmek için bile temel gereksinimleri aşar bulmaz http://wso2.com/products/web-services-framework/php/ gibi bir şey kullanmanız gerekecek RM dahili destek yok.

SOAP zarf oluşturma PHP'de çok karışık, isim alanları yaratma şekli, xsd: nil, xsd: anytype ve eski tarz sabun SOAP Kodlama kullanan (Tanrı ne kadar farklı olduğunu biliyor) içinde SOAP mesajlar.

Bütün bu karışıklıktan REST'e sadık kalarak kaçının, REST WWW’nin başından beri kullandığımız çok büyük bir şey değil. Sadece bunu yaptığımızda fark ettik http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm rapor çıktığında RESTFul Servislerini uygulamak için HTTP yeteneklerini nasıl kullanabileceğimizi gösterir. HTTP doğal olarak REST'tir, bu sadece HTTP kullanmanın hizmetlerinizi RESTFul yapması anlamına gelmez.

SOAP, HTTP'nin temel yeteneklerini ihmal eder ve HTTP'yi bir taşıma protokolü olarak görür, bu nedenle teoride bağımsız olarak bir aktarım protokolüdür (pratikte [google değilse!] SOAP Eylem başlığı? .

JSON adaptasyonu arttıkça ve javascriptli HTML5 ile JSON ile olgunlaşan REST servislerle başa çıkmanın en yaygın yolu haline geldi. JSON Schema, gerektiğinde WADL ile birlikte işletme düzeyinde çözümler (hala erken aşamada) için de kullanılabilir.

REST ve JSON için PHP desteği, sahip olduğu yerleşik SOAP desteğinden kesinlikle daha iyidir.

Buraya birkaç BUZZ kelime 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 spesifikasyonu için SOAP 'ı çok seviyorum, bu iyi bir özellik ve Enterprise JSON uyarlamasında düşünen birinin kesinlikle alan düzeyinde şifreleme gibi JSON için benzer bir şeyle gelmesi gerekiyorsa.

4
shivaspk

SOAP Web servislerine hizmet odaklı bir yaklaşımı ifade eder - bunlardan biri hizmetlerle etkileşime girmenin birincil yöntemidir (ya da fiiller). REST, nesnenin (veya ismin) merkezi aşamaya geçtiği kaynak odaklı bir yaklaşımı benimser.

4

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

Orkestrasyonlu makineyi makine servislerine (ESB) ve harici servislere dahil olmak üzere hız, güvenilirlik ve güvenlik nedenleriyle SOAP üzerinden TCP kullanın. Hizmet tanımını değiştirdiğinizde, düzenleme WSDL değişikliğinden bir hata doğurur ve hemen anlaşılır ve yeniden oluşturulabilir/konuşlandırılabilir.

Aynısını yapabileceğinden emin değilim REST - Düzeltilmeyi ya da seyrediyorum! REST ile servis tanımını değiştirin - 400 (ya da her neyse) dönene kadar hiçbir şey bilmiyor.

3
BlueChippy

Farklı sistemler ve diller arasında birlikte çalışabilirlik arıyorsanız, kesinlikle REST'e gidecektim. Örneğin, .NET ile Java arasında SOAP çalışmasını sağlamaya çalışırken birçok sorun yaşadım.

2
neu242

hangisinin daha hızlı olduğunu bulmak için bir ölçüt 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ü
2
Sonador

Eski bir soru ama bugün hala geçerli… işletme alanındaki birçok geliştirici hala onu kullanıyor.

Çalışmam IoT (Nesnelerin İnterneti) çözümlerini tasarlamak ve geliştirmek. Bulut ile iletişim kuran küçük gömülü aygıtlar için kod geliştirme içerir.

Belli ki REST artık yaygın bir şekilde kabul görüyor ve kullanışlıdır ve web için varsayılan olarak belirsiz olan bir standarttır, Microsoft’un bile Azure’da dahil olduğu REST desteği vardır. Güvenmem gerekiyorsa SOAP Yapmak istediğim şeyi yapamadım, çünkü küçük gömülü cihazlar için çok büyük, hacimli ve sinir bozucu.

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

0
Remixed123

1. deneyimimden. REST, zaten oluşturulmuş olan URL’ye erişme seçeneği sunacağını söyleyebilirim. eg-> google'da bir kelime araması. Bu URL, REST için web servisi olarak kullanılabilir. SOAP'ta, kendi web servisinizi oluşturabilir ve SOAP istemcisi üzerinden erişebilirsiniz.

  1. REST, metni, JSON, XML biçimini destekler. Dolayısıyla iki uygulama arasında iletişim kurmak için daha çok yönlüdür. SOAP mesaj iletişimi için yalnızca XML biçimini desteklerken.
0
Shalini Baranwal