SOAP ile REST karşılaştırması (farklar)

Bir web hizmeti iletişim protokolü olarak SOAP ve REST arasındaki farklar hakkında makaleler okudum, ancak bence SOAP yerine REST için en büyük avantajları şunlardır:

1. REST daha dinamiktir, UDDI (Evrensel Açıklama, Keşif ve Entegrasyon) oluşturmaya ve güncellemeye gerek yoktur.

2. REST yalnızca XML biçimiyle sınırlı değildir. RESTful web hizmetleri düz metin / JSON / XML gönderebilir.

Ancak SOAP daha standartlaştırılmıştır (Örn: güvenlik).

Peki, bu noktalarda doğru muyum?

Ne yazık ki, REST'in etrafında birçok yanlış bilgi ve yanlış anlama var. Sadece sorunuz ve @ cmd'nin cevabı bunları değil, Yığın Taşması konusundaki soru ve cevapların çoğunu da yansıtır.

Birincisi bir protokol (veya en azından olmaya çalışır) ve ikincisi mimari bir stil olduğundan SOAP ve REST doğrudan karşılaştırılamaz. Bu muhtemelen etrafındaki karışıklık kaynaklarından biridir, çünkü insanlar REST'i SOAP olmayan herhangi bir HTTP API'sine çağırırlar.

İşleri biraz zorlamak ve bir karşılaştırma yapmaya çalışmak, SOAP ve REST arasındaki temel fark, istemci ve sunucu uygulamaları arasındaki bağlantı derecesidir. SOAP istemcisi, sunucuya sıkıca bağlı özel bir masaüstü uygulaması gibi çalışır. İstemci ve sunucu arasında katı bir sözleşme var ve her iki taraf da bir şey değiştirirse her şeyin kırılması bekleniyor. Herhangi bir değişikliğin ardından sürekli güncellemelere ihtiyacınız vardır, ancak sözleşmenin takip edilip edilmediğini belirlemek daha kolaydır.

Bir REST istemcisi daha çok bir tarayıcı gibidir. Protokolün ve standart yöntemlerin nasıl kullanılacağını bilen genel bir istemcidir ve bir uygulamanın buna uyması gerekir. Ek yöntemler oluşturarak protokol standartlarını ihlal etmez, standart yöntemlerden yararlanır ve medya türünüzde bunlarla eylemler oluşturursunuz. Doğru yapılırsa, daha az bağlantı vardır ve değişiklikler daha zarif bir şekilde ele alınabilir. Bir istemcinin, giriş noktası ve ortam türü hariç, API hakkında sıfır bilgiye sahip bir REST hizmetine girmesi beklenir. SOAP'ta, müşteri kullanacağı her şey hakkında önceden bilgiye ihtiyaç duyar, yoksa etkileşime bile başlamaz. Ayrıca, bir REST istemcisi, sunucunun kendisi tarafından sağlanan isteğe bağlı kod ile genişletilebilir,

Bunlar REST'in ne hakkında olduğunu ve SOAP'tan nasıl farklı olduğunu anlamak için çok önemli noktalar olduğunu düşünüyorum:

• REST, protokolden bağımsızdır. HTTP ile birleştirilmemiş. Bir web sitesinde bir ftp bağlantısını takip edebileceğiniz gibi, bir REST uygulaması standart bir URI şeması olan herhangi bir protokolü kullanabilir.

• REST, CRUD'nin HTTP yöntemleriyle eşlenmesi değildir. Bununla ilgili ayrıntılı bir açıklama için bu cevabı okuyun .

• REST, kullandığınız parçalar kadar standartlaştırılmıştır. HTTP'de güvenlik ve kimlik doğrulama standartlaştırılmıştır, bu nedenle HTTP üzerinden REST yaparken bunu kullanırsınız.

• REST, hipermedya ve HATEOAS olmadan REST değildir . Bu, bir istemcinin yalnızca giriş noktası URI'sini bildiği ve kaynakların istemcinin izlemesi gereken bağlantıları döndürmesi gerektiği anlamına gelir. Bir REST API'sinde yapabileceğiniz her şey için URI desenleri veren bu fantezi dokümantasyon üreteçleri bu noktayı tamamen özlüyor. Yalnızca standardı takip etmesi gereken bir şeyi belgelemekle kalmazlar, bunu yaptığınızda, istemciyi API'nın gelişiminde belirli bir ana bağlarsınız ve API'daki herhangi bir değişiklik belgelenmeli ve uygulanmalıdır, yoksa kırılacaktır.

• REST, ağın mimari tarzıdır. Yığın Taşması'na girdiğinizde, Kullanıcı, Soru ve Cevap ne olduğunu bilirsiniz, medya türlerini bilirsiniz ve web sitesi size bunlara bağlantılar sağlar. Bir REST API aynı şeyi yapmalıdır. Biz İnsanların DİNLENME yerine Sorular ve Cevaplar bağlantılarını içeren bir ana sayfa sahip olmalı- web dizayn, biz bir soruyu görüntülemek için, sen URI almak zorunda olduğunu açıklayan statik belgeler olurdu stackoverflow.com/questions/<id>, kimliği Question.id ile değiştirin ve tarayıcınıza yapıştırın. Bu saçmalık, ama birçok insan REST'in böyle olduğunu düşünüyor.

Bu son nokta yeterince vurgulanamaz. Müşterileriniz dokümantasyondaki şablonlardan URI'ler oluşturuyor ve kaynak sunumlarında bağlantı almıyorsa, bu REST değildir. REST'in yazarı Roy Fielding, bu blog yazısında açıkça belirtti: REST API'lerinin hipermetin güdümlü olması gerekir .

Yukarıdakileri göz önünde bulundurarak, REST'in XML ile sınırlı olmasa da, doğru bir şekilde yapmak için bağlantılarınız için bazı formatları tasarlamanız ve standartlaştırmanız gerektiğini fark edeceksiniz. Köprüler XML'de standarttır, ancak JSON'da yoktur. HAL gibi JSON için taslak standartlar vardır .

Son olarak, REST herkes için değildir ve bunun bir kanıtı, çoğu insanın yanlışlıkla REST olarak adlandırdıkları ve asla bunun ötesine geçmedikleri HTTP API'leriyle sorunlarını çok iyi çözdüğünün bir kanıtıdır. REST'in bazen, özellikle başlangıçta yapılması zordur, ancak sunucu tarafında daha kolay evrim ve müşterinin değişikliklere karşı dayanıklılığı ile zaman içinde ödeme yapar. Hızlı ve kolay bir şekilde bir şeye ihtiyacınız varsa, REST'i doğru yapmaktan çekinmeyin. Muhtemelen aradığınız şey değil. Yıllarca hatta on yıllarca çevrimiçi kalmanız gereken bir şeye ihtiyacınız varsa, REST sizin için.

RESTvs SOAPolduğu değil sormak doğru soru.

RESTAksine SOAPbir değil bir protokol.

RESTbir mimari tarzı ve ağ tabanlı yazılım mimarileri için bir tasarım .

RESTkavramlara kaynak denir. Bir kaynağın temsili vatansız olmalıdır. Bazı ortam türleriyle temsil edilir. Medya türleri bazı örnekler XML, JSONve RDF. Kaynaklar bileşenler tarafından manipüle edilir. Bileşenler, standart bir düzgün arabirim aracılığıyla kaynakları ister ve yönlendirir. HTTP durumunda, bu arayüz mesela standart HTTP op oluşur GET, PUT, POST, DELETE.

Abdülaziz'in sorusuna @ gerçeğini aydınlatmak yapar RESTve HTTPsık sık birlikte kullanılmaktadır. Bu öncelikle HTTP'nin basitliğinden ve RESTful ilkelerine çok doğal eşlenmesinden kaynaklanmaktadır.

Temel REST İlkeleri

İstemci-Sunucu İletişimi

İstemci-sunucu mimarilerinin endişeleri birbirinden çok farklıdır. RESTful tarzında oluşturulan tüm uygulamalar da ilke olarak istemci-sunucu olmalıdır.

vatansız

Sunucuya yapılan her istemci isteği, durumunun tam olarak temsil edilmesini gerektirir. Sunucu, herhangi bir sunucu bağlamı veya sunucu oturumu durumu kullanmadan istemci isteğini tam olarak anlayabilmelidir. Tüm durumun istemcide tutulması gerektiği sonucuna varılır.

cacheable

Önbellek kısıtlamaları kullanılabilir, böylece yanıt verilerinin önbelleğe alınabilir veya önbelleğe alınamaz olarak işaretlenmesi sağlanır. Önbelleğe alınabilir olarak işaretlenen tüm veriler, aynı sonraki isteğe yanıt olarak yeniden kullanılabilir.

Düzgün Arayüz

Tüm bileşenler tek bir düzgün arayüz üzerinden etkileşime girmelidir. Tüm bileşen etkileşimi bu arabirim üzerinden gerçekleştiğinden, farklı hizmetlerle etkileşim çok basittir. Arayüz aynı! Bu aynı zamanda uygulama değişikliklerinin tek başına yapılabileceği anlamına gelir. Bu tür değişiklikler, üniform arayüz her zaman değişmediği için temel bileşen etkileşimini etkilemez. Bir dezavantajı, arayüz ile sıkışmış olmasıdır. Arabirim değiştirilerek belirli bir hizmete bir optimizasyon sağlanabilirse, REST bunu yasakladığı için şansınız kalmaz. Bununla birlikte, parlak tarafta, REST web için optimize edilmiştir, bu nedenle HTTP üzerinden REST'in inanılmaz popülaritesi!

Yukarıdaki kavramlar REST'in tanımlayıcı özelliklerini temsil eder ve REST mimarisini web hizmetleri gibi diğer mimarilerden farklı kılar. Bir REST hizmetinin bir web hizmeti olduğunu, ancak bir web hizmetinin mutlaka bir REST hizmeti olmadığını belirtmek yararlıdır.

Bu blog Bkz yazısı üzerine DİNLENME Tasarım İlkeleri hakkında daha fazla ayrıntı için DİNLENME ve yukarıda belirtilen kurşunlar.

EDIT: içeriği yorumlara göre güncelleyin

SOAP ( Basit Nesne Erişim Protokolü ) ve REST ( Temsil Durum Aktarımı ) her ikisi de güzel. Bu yüzden onları karşılaştırmıyorum. Bunun yerine, REST kullanmayı tercih ettiğimde ve SOAP olduğunda resmi tasvir etmeye çalışıyorum.

Yük nedir?

İnternet üzerinden veri gönderildiğinde, iletilen her birim hem başlık bilgisini hem de gönderilen gerçek verileri içerir. Üstbilgi, paketin kaynağını ve hedefini belirtirken, gerçek veriler yük olarak adlandırılır . Genel olarak, yük, bir uygulama adına taşınan veriler ve hedef sistem tarafından alınan verilerdir.

Şimdi, örneğin, bir Telgraf göndermek zorundayım ve hepimiz biliyoruz ki, telgrafın maliyeti bazı kelimelere bağlı olacaktır.

Öyleyse bana aşağıdaki iki mesajdan hangisini göndermenin daha ucuz olduğunu söyleyin?

<name>Arin</name>

veya

"name": "Arin"

Her ikisinin de aynı mesajı temsil eden her ikisinin maliyet açısından daha ucuz olmasına rağmen cevabınızın ikincisi olacağını biliyorum.

Bu yüzden JSON formatında ağ üzerinden veri göndermenin veri yükü ile ilgili XML formatında göndermekten daha ucuz olduğunu söylemeye çalışıyorum .

İşte REST'in SOAP'a göre ilk avantajı veya avantajları . SABUN sadece XML'i destekler, ancak REST metin, JSON, XML, vb.

Şimdi, SOAP tek XML'yi destekliyor, ancak aynı zamanda avantajları var.

Gerçekten mi! Nasıl?

SOAP, XML'de üç şekilde Zarf kullanır - mesajda ne olduğunu ve nasıl işleneceğini tanımlar.

Veri türleri için bir dizi kodlama kuralı ve son olarak prosedür çağrılarının ve yanıtlarının düzeni toplandı.

Bu zarf bir aktarım (HTTP / HTTPS) aracılığıyla gönderilir ve bir RPC (Uzaktan Yordam Çağrısı) yürütülür ve zarf, XML biçimli bir belgedeki bilgilerle birlikte döndürülür.

Önemli olan nokta olmasıdır SOAP avantajlarından biri kullanılmasıdır “jenerik” taşıma ama DİNLENME HTTP / HTTPS kullanır . SOAP, isteği göndermek için hemen hemen her aktarımı kullanabilir, ancak REST kullanamaz. Burada SOAP kullanma avantajımız var.

Yukarıdaki paragrafta daha önce bahsettiğim gibi “REST HTTP / HTTPS kullanıyor” , bu yüzden bu kelimeler üzerinde biraz daha derine inin.

HTTP üzerinden REST hakkında konuştuğumuzda, HTTP uygulanan tüm güvenlik önlemleri devralınır ve bu aktarım düzeyi güvenliği olarak bilinir ve iletileri yalnızca telin içindeyken korur , ancak diğer tarafa ilettiğinizde verilerin işleneceği gerçek noktaya ulaşmadan önce kaç aşamadan geçmesi gerektiği. Ve elbette, tüm bu aşamalar HTTP'den farklı bir şey kullanabilir. Yani dinlenme tamamen daha güvenli değil, değil mi?

Ancak SOAP , REST gibi SSL'yi de desteklemektedir ve ayrıca bazı kurumsal güvenlik özellikleri ekleyen WS-Security'yi de desteklemektedir . WS-Security , mesajın oluşturulmasından tüketimine kadar koruma sağlar . Dolayısıyla, WS-Security kullanılarak önlenebilecek her türlü boşlukta ulaşım seviyesi güvenliği için.

Bunun dışında, REST HTTP protokolü ile sınırlı olduğundan, işlem desteği ne ACID uyumlu değildir ne de dağıtılmış ulus ötesi kaynaklar arasında iki aşamalı kesinleştirme sağlayamaz.

Ancak SOAP, hem kısa vadeli işlemler için ACID tabanlı işlem yönetimi hem de uzun vadeli işlemler için tazminat tabanlı işlem yönetimi için kapsamlı desteğe sahiptir . Ayrıca , dağıtılmış kaynaklar arasında iki aşamalı taahhüdü destekler .

Herhangi bir sonuç çıkarmıyorum, ancak güvenlik, işlem vb. Temel endişeler ise SOAP tabanlı web hizmetini tercih edeceğim.

İşte aşağıdaki koşullar yerine getirildiğinde A RESTful tasarımının uygun olabileceğini söyledikleri "Java EE 6 Eğitimi" . Bir bak.

Umarım cevabımı okumaktan hoşlanırsın.

DİNLENME ( RE sunumsal S Tate T ransfer)
RE sunumsal S Tate bir nesne olan T biz Nesne durumunu göndermek, DİNLENME biz Nesne göndermeyen yani olduğu ransferred. REST mimari bir stildir. SOAP gibi pek çok standart tanımlamaz. REST, genel API'ları (yani Facebook API, Google Maps API) veri üzerinde CRUD işlemlerini gerçekleştirmek için internet üzerinden göstermek içindir. REST, tek bir tutarlı arabirim aracılığıyla adlandırılmış kaynaklara erişmeye odaklanmıştır.

SABUN ( S uygu O Nesne A Dışı Erişim P rotocol)
SABUN kendi protokolünü getiriyor ve hizmetler gibi uygulama mantığı (veri yok) parçalarını açığa odaklanır. SOAP işlemleri ortaya koyar. SOAP, adlandırılmış işlemlere erişmeye odaklanmıştır, her işlem bazı iş mantığı uygular. SOAP yaygın olarak web servisleri olarak adlandırılsa da bu yanlış adlandırmadır. Web ile ilgili bir şey varsa SOAP çok azdır. REST, URI'lere ve HTTP'ye dayalı gerçek Web hizmetleri sağlar .

Neden REST?

• REST standart HTTP kullandığı için neredeyse her şekilde çok daha basittir.
• REST'in uygulanması daha kolaydır, daha az bant genişliği ve kaynak gerektirir.
• REST, SOAP'ın yalnızca XML'e izin verdiği gibi birçok farklı veri formatına izin verir.
• REST, JSON desteğinden dolayı tarayıcı istemcileri için daha iyi destek sağlar.
• REST daha iyi performans ve ölçeklenebilirliğe sahiptir. REST okumaları önbelleğe alınabilir, SOAP tabanlı okumalar önbelleğe alınamaz.
• Güvenlik büyük bir endişe kaynağı değilse ve sınırlı kaynağımız varsa. Ya da halka açık olarak diğer geliştiriciler tarafından kolayca kullanılacak bir API oluşturmak istiyoruz, o zaman REST ile gitmeliyiz.
• Stateless CRUD işlemlerine ihtiyacımız varsa, REST ile devam edin.
• REST, sosyal medya, web sohbeti, mobil hizmetler ve Google Haritalar gibi Genel API'larda yaygın olarak kullanılmaktadır.
• RESTful hizmeti, POST olarak application/xmlveya application/jsonPOST için istek kabul parametresine ve /user/1234.jsonGET /user/1234.xmliçin GET'e bağlı olarak aynı kaynak için çeşitli MediaTypes döndürür .
• REST hizmetleri, doğrudan son kullanıcı tarafından değil, istemci tarafı uygulaması tarafından çağrılmalıdır.
• REST'teki ST , S tate T ransfer'dan gelir . Sunucuyu depolamak yerine durumu aktarırsınız, bu da REST hizmetlerini ölçeklendirilebilir hale getirir.

Neden SABUN?

• SOAP'ın uygulanması çok kolay değildir ve daha fazla bant genişliği ve kaynak gerektirir.
• SOAP ileti isteği REST ile karşılaştırıldığında daha yavaş işlenir ve web önbellekleme mekanizması kullanılmaz.
• WS-Security: SOAP SSL'yi (tıpkı REST gibi) desteklerken, bazı kurumsal güvenlik özellikleri ekleyen WS-Security'yi de destekler.
• WS-AtomicTransaction: Bir hizmet üzerinden ACID İşlemlerine ihtiyacınız var, SOAP'a ihtiyacınız olacak.
• WS-ReliableMessaging: Uygulamanız Eşzamansız işleme ve garantili düzeyde güvenilirlik ve güvenlik gerektiriyorsa. Dinlenmenin standart bir mesajlaşma sistemi yoktur ve müşterilerin yeniden deneyerek iletişim hatalarıyla başa çıkmalarını bekler.
• Güvenlik büyük bir endişe kaynağıysa ve kaynaklar sınırlı değilse, SOAP web servislerini kullanmalıyız. Ödeme ağ geçitleri, finans ve telekomünikasyon ile ilgili işler için bir web hizmeti oluşturuyor gibi, yüksek güvenlik gerektiği için SOAP ile gitmeliyiz.

kaynak1
kaynak2

Dinlenme ve Sabun Arasındaki Fark

SABUN

1. SOAP bir protokoldür.
2. SOAP, Basit Nesne Erişim Protokolü anlamına gelir.
3. SOAP bir protokol olduğu için REST'i kullanamaz.
4. SOAP, iş mantığını ortaya çıkarmak için hizmet arabirimlerini kullanır.
5. SOAP, kesinlikle uyulacak standartları tanımlar.
6. SOAP, REST'ten daha fazla bant genişliği ve kaynak gerektirir.
7. SOAP kendi güvenliğini tanımlar.
8. SOAP yalnızca XML veri biçimine izin verir.
9. SOAP, REST'ten daha az tercih edilir.

DİNLENME

1. REST mimari bir stildir.
2. REST, Temsil Edici Devlet Transferi anlamına gelir.
3. REST, bir kavram olduğu ve HTTP, SOAP gibi herhangi bir protokolü kullanabildiği için SOAP web servislerini kullanabilir.
4. REST, iş mantığını ortaya çıkarmak için URI kullanır.
5. REST, SOAP gibi çok fazla standart tanımlamaz.
6. REST, SOAP'tan daha az bant genişliği ve kaynak gerektirir.
7. RESTful web hizmetleri, güvenlik önlemlerini temel taşımacılıktan miras alır.
8. REST, Düz metin, HTML, XML, JSON vb. Gibi farklı veri formatlarına izin verir.
9. REST, SOAP'tan daha fazla tercih edilir.

Daha fazla ayrıntı için lütfen buraya bakın

IMHO, iki farklı şey olan SOAP ve REST'i karşılaştıramazsınız.

SOAP bir protokoldür ve REST bir yazılım mimari modelidir. SOAP vs REST için internette bir çok yanlış anlama var .

SOAP , web hizmeti etkin uygulamaların birbirlerini internet üzerinden iletişim kurmak için kullandığı XML tabanlı mesaj biçimini tanımlar. Bunu yapabilmek için uygulamaların mesaj sözleşmesi, veri türleri vb. Hakkında önceden bilgi sahibi olması gerekir.

REST , bir URL'den bir sunucunun durumunu (kaynaklar olarak) temsil eder.

Her şeyden önce: resmi olarak, doğru soru web services + WSDL + SOAPvs olacaktır REST.

Web hizmeti gevşek anlamda kullanılmasına rağmen, web sayfaları yerine veri aktarmak için HTTP protokolünü kullanırken , resmen bu fikrin çok özel bir şeklidir. Tanıma göre, REST "web servisi" değildir.

Ancak pratikte herkes bunu görmezden geliyor, hadi görmezden gelelim

Zaten teknik cevaplar var, bu yüzden biraz sezgi sağlamaya çalışacağım.

Diyelim ki, başka bir programlama dilinde uygulanan uzak bir bilgisayarda bir işlevi çağırmak istiyorsunuz (buna genellikle uzaktan yordam çağrısı / RPC denir ). Bu işlevin, onu yazan kişi tarafından sağlanan belirli bir URL'de bulunabileceğini varsayın. Bir şekilde (bir şekilde) bir mesaj göndermeniz ve biraz yanıt almanız gerekir. Dolayısıyla, dikkate alınması gereken iki ana soru var.

• göndermen gereken mesajın biçimi nedir
• mesaj nasıl ileri ve geri taşınmalı

İlk soru için resmi tanım WSDL'dir . Bu, detaylı ve katı biçimde parametrelerin ne olduğunu, türlerini, adlarını, varsayılan değerlerini, çağrılacak işlevin adını vb. Açıklayan bir XML dosyasıdır. Buradaki örnek WSDL , dosyanın insan olduğunu gösterir. - okunabilir (ancak kolay değil).

İkinci soru için çeşitli cevaplar var. Bununla birlikte, pratikte kullanılan tek kişi SOAP'tır . Ana fikri: önceki XML'yi (gerçek mesaj) başka bir XML'e (kodlama bilgileri ve diğer yararlı şeyler içeren) sarın ve HTTP üzerinden gönderin. Her zaman bir gövde bulunduğundan, HTTP'nin POST yöntemi iletiyi göndermek için kullanılır .

Bu yaklaşımın ana fikri, bir URL'yi bir işleve , yani bir eyleme eşlemenizdir . Bu nedenle, bazı sunucularda bir müşteri listeniz varsa ve birini görüntülemek / güncellemek / silmek istiyorsanız, 3 URL'niz olması gerekir:

• myapp/read-customer ve iletinin gövdesinde, okunacak müşterinin kimliğini iletin.
• myapp/update-customer ve vücutta, müşterinin kimliğini ve yeni verileri geçirin
• myapp/delete-customer ve vücuttaki kimlik

REST yaklaşımı olayları farklı görür. Bir URL bir eylemi değil, bir şeyi temsil etmelidir ( REST dilinde kaynak olarak adlandırılır ). HTTP protokolü (zaten kullandığımız) fiilleri desteklediğinden, bu fiilleri o şey üzerinde gerçekleştirilecek eylemleri belirtmek için kullanın .

Bu nedenle, REST yaklaşımıyla, URL'de müşteri numarası 12 bulunur myapp/customers/12. Müşteri verilerini görüntülemek için URL'yi bir GET isteğiyle vurursunuz. Silmek için, aynı URL, bir DELETE fiiliyle. Tekrar güncellemek için, bir POST fiili ile aynı URL ve istek gövdesindeki yeni içerik.

Bir hizmetin gerçekten RESTful olarak kabul edilmesi için yerine getirmesi gereken gereksinimler hakkında daha fazla bilgi için Richardson olgunluk modeline bakın . Makale örnekler veriyor ve daha da önemlisi, bir (sözde) SOAP hizmetinin neden bir seviye-0 REST hizmeti olduğunu açıklıyor (seviye-0 bu modele düşük uyumluluk anlamına gelse de, rahatsız edici değil ve yine de yararlı Çoğu durumda).

Zaten birçok cevapta yer alan diğer pek çok şey arasında, SOAP'ın bir sözleşme tanımlamasını sağladığını, desteklenen işlemleri tanımlayan WSDL'yi, karmaşık türleri vb. Şahsen ben, iç kurumsal uygulamalar arasındaki karmaşık arayüzler için SOAP'ı, dış dünya ile kamusal, daha basit, vatansız arayüzler için REST'i seçerdim.

İçin ek:

++ REST'e yaklaşırken sıklıkla yapılan bir hata, bunu "URL'lere sahip web hizmetleri" olarak düşünmektir - REST'i SOAP gibi başka bir uzak yordam çağrısı (RPC) mekanizması olarak düşünmek, ancak düz HTTP URL'leri aracılığıyla ve SOAP'ın iri olmadan çağırmaktır XML ad alanları.

++ Aksine, REST'in RPC ile pek ilgisi yoktur. RPC hizmet odaklı ve eylemlere ve fiillere odaklanırken, REST kaynak yönelimlidir ve bir uygulama içeren şeyleri ve isimleri vurgular.

Bu cevapların birçoğu, tamamen REST için temel olan hiper ortam kontrollerinden (HATEOAS) bahsetmeyi tamamen unuttu. Birkaç kişi buna değindi, ama gerçekten çok iyi açıklamadı.

Bu makalede , belirli SOAP özellikleri üzerinde yabani otlara girmeden kavramlar arasındaki farkı açıklamalıdır.