Bir web servisini SOAP veya REST servisi olarak gösterme seçiminde belirleyici faktörler nelerdir?


30

SOAP tüketimini görebildiğim kadarıyla SOAP yığını gerektirir, bu nedenle müşterilerinizin tüketmesi daha zordur, yani POST verilerini ve başlıkları doğru şekilde biçimlendiren bir SOAP yığınının olmasını sağlamaları gerekir ve ardından size biraz geri veri yapısı, REST ile sadece sorgu dizesindeki argümanlarla bir HTTP GET isteği yaparsınız ve muhtemelen XML olduğunu düşündüğüm bir metni geri alırsınız.

Öyleyse, SOAP'ın ek yükü / karmaşıklığı size ne veriyor, ne zaman ihtiyacınız var ve ne zaman ve ne zaman onsuz yapmalısınız?

Yanıtlar:


17

Daha önce bir REST API uyguladım ve çok beğendim. Genel olarak, SOAP üzerinden REST uyguladığınızda , istemciniz / sunucunuz daha diktir, yani istemcilerinizi etkilemeden sunucuyu daha serbest bir şekilde değiştirebilirsiniz. Bu ortogonalite, HTTP fiilleri aracılığıyla daha soyut ve daha iyi tanımlanmış bir iletişim kullanılmasından kaynaklanmaktadır. Ayrıca, REST yanıtlarınızda yerleşik olan köprülerin kullanılması, API'nizi nispeten ağrısız şekilde genişletmenizi ve büyütmenizi kolaylaştırır. Müşterilerin, daha fazla bilgi için bir web sayfasındaki bağlantıları araştırmak gibi bir insan gibi yeni kaynaklara ulaşmak için bu gömülü bağlantıları izlemeleri beklenir.

Bununla birlikte, SOAP kullanmaları gerektiği söylenen bazı iş arkadaşlarım vardı ve bu konuda sürekli şikayette bulundular. Bu yüzden ikisini biraz daha ayrıntılı araştırmaya başladım.

Genel olarak bulduğum, yüzlerce, binlerce veya milyonlarca müşteriniz olduğunda REST'in yüksek oranda dağıtılmış uygulamalar için çok uygun olduğu . Bunun bir nedeni yukarıda belirtilen dikliktir, diğeri ise HTTP kullandığınız için ücretsiz olarak önbelleğe almanızdır.

SOAP, bir müşteri için iki veya daha küçük bir API'ye ihtiyacınız olduğunda hızlı bir şekilde gitmek ve ölçeklenebilirlik konusunda endişelenmemek için daha hızlı bir yol olabilir. Kaynakların etrafında yapılandırılmış bir mimariye sahip değilseniz , REST'i uygulayabilmeniz için uygulamanızı yeniden yapılandırmanız biraz zaman alabileceğinden, size daha uygun olabilir.


2
Kaynak paradigması ve devlet eksikliği nedeniyle HTTP yüzünden önbellekleme elde edersiniz.
dietbuddha

@dietbuddha HTTP size ücretsiz uygulamayı verir.
Jacob Raihle

17

Küçük bir nokta olabilir, ancak REST tamamen HTTP'ye dayanmaktadır.

SOAP, HTTP gerektirmez ve istediğiniz taşıma türünü kullanmakta serbestsiniz.

SOAP mesajları asenkron ve güvenilir bir şekilde yönlendirilirken, REST hemen hemen senkron bir paradigmadır.

REST, gönderdiğiniz ve aldığınız verilerin neye benzemesi gerektiği hakkında hiçbir şey söylemez. WADL var, ancak çoğunlukla API'nin doğru belgelenmesine güveniyorsunuz. SOAP, veri tanımlamasını daha az hataya açık hale getirmek için XML teknolojilerinde bir sirke sahiptir. WSDL, Şema ...

Günün sonunda REST, size HTTP tabanlı bir dosya sistemi sunar. Sisteminiz bu paradigmaya uyuyorsa - o zaman iyi bir seçim olabilir.


Birden fazla nakliyeden bahsetmek için +1. Gerçekten bir taşıma-agnostik protokolüne ihtiyacınız varsa (örneğin, SMTP veya benzeri bir işlemi desteklemektedir), REST çıkar. Genellikle HTTP yeterince iyidir, ancak ...
sleske

6
REST'in HTTP'ye nasıl bağlandığını anlamıyorum? Bu uygulama detayı. Çoğu REST uygulaması HTTP üzerinden gerçekleştirilir, ancak FTP gibi REST'i neden diğer protokollere uygulayamadığımı anlamıyorum.
edalorzo

REST, belirli bir protokol ile olan iletişimi sınırlandırmaz ref: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
nmtoken

7

Öyleyse, SOAP'ın ek yükü / karmaşıklığı size ne veriyor, ne zaman ihtiyacınız var ve ne zaman ve ne zaman onsuz yapmalısınız?

İkisi arasındaki en büyük fark, REST'in SOAP olmadığı durumlarda vatansız olması gerektiğidir . Uygulamada birçok REST uygulaması aslında OAuth gibi bir şey aracılığıyla oturumdaki bazı durumları uygulamaktadır.

Diğer bir fark ise REST'in çok "kaynak" veya isim odaklı olmasıdır . CRUD işlemleri ile kaynaklarla etkileşime girersiniz. Bu paradigmaya uymayan her şey hantal ve garip hale gelir.

SOAP ise sadece bir RPC (uzaktan prosedür çağrısı) protokolüdür . Paradigma ile gelmiyor, sadece taşıma katmanı.


1
Hem SOAP hem de REST, yalnızca bir sonuç elde etmek için bir araçtır. Görev için uygun olabilir veya olmayabilir. Böylece REST de bir taşıma katmanı olarak görülebilir. Durum / az görünüm bile geçerli değil: hem lezzetleri hem de diğer API türleriyle tasarlayabilirsiniz. Hem SOAP hem de REST bitiş noktası olan çift bir API'niz bile olabilir. Ve bir XML-RPC bitiş noktası. Ve bir Apache Thrift bitiş noktası. Ve bir Google Protokolü Tamponları bitiş noktası. Ve başka. Günün sonunda her şey sadece bir RPC.
JensG

4

REST, postayı da kullanır. Aslında, REST kullanırken http fiilleri size hangi işlemlerin devam ettiğini söyler.

REST ve SOAP internet üzerinden veri aktarmanın sadece farklı standartlarıdır.

Her ikisini de kullanmış olsaydım, web servisinizi tüketecek kişilerin .net ve Visual Studio'yu kullandığını bilmiyorsanız, genellikle SOAP yerine REST kullanmanızı öneririm. SOAP kullanırken sizin için işin çoğunu yapan .net VS dışında bir REST web servisini kullanmak genellikle daha kolaydır.


4
Java'da da iyi SOAP desteği var.

4

Bahsetmek istediğim bir şey birlikte çalışabilirlik - servisinizi .NET'te yazılmış bir uygulamadan arayacaksanız ve sunucu Java ile yazılmışsa (veya başka bir kombinasyonda), REST için gidin. SOAP uygulamaları arasında daha fazla düşünmeden rahatsız etmek için çok fazla hafif uyumsuzluk gördüm.


2
Anlaşmak. SOAP endüstri standardıdır ancak aşırı karmaşıktır, tonlarca kırılmış veya tamamlanmamış uygulamalara yol açar. Bunun yanı sıra, SOAP tipik olarak diğer tüm yaklaşımlarla karşılaştırıldığında performans ve trafik açısından en büyük ayakizine sahiptir.
JensG

1

Yalnızca SOAP ve REST'i uygulama gereksinimlerinize göre ölçmenize yardımcı olacak basit ve görsel bir kılavuz istiyorsanız ...

Vijay Prasad Gupta birlikte basit, faydalı bir akış şeması hazırladı.

Akış şemasına doğrudan bağlantı: https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit

Makaleye bağlantı: https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-protocol-for-your-needs


Bu aslında oldukça iyi bir akış şeması. Buradaki tek bir cevabın SOAP'ın REST'e göre avantajlarına değinmediğine şaşırdım. Bu akış şeması olsa da. Akış çizelgesini, buna cevap vermek yerine sadece bağlantıya uyduğundan emin olmak için bağlamak yerine bir görüntü olarak ekleyebilir miyim?
17'de

-2

Şimdi 2015 oldu. SOAP'ın şimdiye dek öldüğünü ümit ediyordum ama yine de kötü bir koku gibi duruyor. "Temel" uygulamalardan en basit olanı dışında, bir SOAP servisiyle entegrasyon zorluklarla donmuş. Çoklu uygulamaların ve ince (ve çok da ince olmayan) uyumsuzlukların tuhaflıkları ile birlikte birçok seviyede birçok seçeneğe sahip karmaşık bir mimaridir. Bununla hiç iyi bir deneyimim olmadı. Öte yandan, REST bir esintidir: herkes HTTP'yi anlar. Çoğu durumda, JSON XML InfoSet'ten çok daha fazla yardımcı programa sahiptir.

Size SOAP'ın karmaşıklığı hakkında bir fikir vermek için, bir SOAP kütüphanesini projenize entegre etmeyi deneyin. Java için, en temel Apache Axis2 istemcisi (basit ADB veri bağlama kullanarak) 23 yeni JAR'ı çeker. Yirmi üç! 20 MB kütüphane bloğu. CXF benzer: En son saydığımda 21 JAR.

Gerçekten istiyorsan, basit bir HTTP kütüphanesiyle REST yapabilirsin.


1
Bu daha çok bir rant gibi okur, bkz Cevap Nasıl
tatarcık

Haklısın. Üzgünüm, o sırada SOAP çorbası içindeydim: D
Cornel Masson

1
Aynı şikayeti 90'lı yıllarda CORBA / IDL ile de tekrar yaşadık. Sonra aniden "Basit Nesne Erişim Protokolü" .. basit olacak! Serin olacak! Hızlı olacak. On yıl sonra, çok karmaşık olarak kabul edilir. JSON (IMAO öğrenci laboratuarı ayarlarında veri aktarımı işlemleri için gerçekten kare bir tekerleği veya "Ne yaptığımı biliyorum" hızlı düzeltme durumları) ve RESTful ops geliyor. Durulayın, tekrarlayın ...
David Tonhofer

Korkarım ki SOAP hakkındaki her gerçek ifade rant olarak okunmalı. Tasarım gereği enteresan ve size sadece biraz veri göndermek istediğiniz birçok seçenek sunuyor. Çalıştığım birkaç SOAP arayüzüyle ilgili olarak, her biri oldukça yedekli bir karışıklıktı (tam olarak SOAP'ın hatası değil, ancak SOAP'a olan yakınlık, bloatware'e olan yakınlık ile ilişkili). Bağırdığım için özür dilerim.
maaartinus
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.