SOAP vs REST (farklılıklar)

Ne yazık ki REST ile ilgili pek çok yanlış bilgi ve yanlış kanı var. Sadece sizin sorunuz ve @cmd'nin cevabı değil, Stack Overflow'daki konuyla ilgili soru ve cevapların çoğu bunları yansıtıyor. SOAP ve REST doğrudan karşılaştırılamaz, çünkü birincisi bir protokoldür (ya da en azından öyle olmaya çalışır) ve ikincisi bir mimari stildir. Bu muhtemelen kafa karışıklığının kaynaklarından biridir, çünkü insanlar SOAP olmayan herhangi bir HTTP API'sini REST olarak adlandırmaya eğilimlidir. İşleri biraz zorlayarak bir karşılaştırma yapmaya çalışırsak, SOAP ve REST arasındaki temel fark, istemci ve sunucu uygulamaları arasındaki bağlantı derecesidir. Bir SOAP istemcisi, sunucuya sıkı sıkıya bağlı özel bir masaüstü uygulaması gibi çalışır. İstemci ve sunucu arasında katı bir sözleşme vardır ve her iki taraf da herhangi bir şeyi değiştirirse her şeyin bozulması beklenir. 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 tespit etmek daha kolaydır. REST istemcisi daha çok bir tarayıcı gibidir. Bir protokolün ve standartlaştırılmış yöntemlerin nasıl kullanılacağını bilen genel bir istemcidir ve bir uygulama bunun içine sığmalıdır. Ekstra yöntemler oluşturarak protokol standartlarını ihlal etmezsiniz, standart yöntemlerden yararlanırsınız ve medya türünüzde bunlarla eylemler oluşturursunuz. Doğru yapılırsa, daha az bağlantı olur ve değişiklikler daha zarif bir şekilde ele alınabilir. Bir istemcinin, giriş noktası ve medya türü dışında API hakkında sıfır bilgiye sahip olarak bir REST hizmetine girmesi beklenir. SOAP'ta, istemcinin kullanacağı her şey hakkında önceden bilgi sahibi olması gerekir, aksi takdirde etkileşime başlamaz bile. Ayrıca, bir REST istemcisi, sunucunun kendisi tarafından sağlanan isteğe bağlı kod ile genişletilebilir; bunun klasik örneği, istemci tarafında başka bir hizmetle etkileşimi yönlendirmek için kullanılan JavaScript kodudur. Bence bunlar REST'in ne olduğunu ve SOAP'tan farkını anlamak için en önemli noktalardır:

• REST protokolden bağımsızdır. HTTP'ye bağlı değildir. Bir web sitesindeki ftp bağlantısını takip edebilmeniz gibi, bir REST uygulaması da standartlaştırılmış bir URI şeması olan herhangi bir protokolü kullanabilir.
• REST, CRUD ile HTTP yöntemlerinin eşleştirilmesi değildir. Bu konuda ayrıntılı bir açıklama için bu yanıtı okuyun.
• REST, kullandığınız parçalar kadar standartlaştırılmıştır. HTTP'deki güvenlik ve kimlik doğrulama standartlaştırılmıştır, bu nedenle HTTP üzerinden REST yaparken kullandığınız şey budur.
• REST, hypermedia ve HATEOAS olmadan REST değildir. Bu, bir istemcinin yalnızca giriş noktası URI'sini bildiği ve kaynakların istemcinin takip etmesi gereken bağlantıları döndürmesi gerektiği anlamına gelir. Bir REST API'sinde yapabileceğiniz her şey için URI kalıpları veren bu süslü dokümantasyon oluşturucular noktayı tamamen kaçırıyor. Sadece standardı takip etmesi gereken bir şeyi belgelemekle kalmıyorlar, aynı zamanda bunu yaptığınızda, istemciyi API'nin evrimindeki belirli bir ana bağlıyorsunuz ve API'deki herhangi bir değişiklik belgelenmeli ve uygulanmalıdır, aksi takdirde bozulacaktır.
• REST, web'in kendisinin mimari tarzıdır. Stack Overflow'a girdiğinizde, Kullanıcı, Soru ve Yanıtın ne olduğunu bilirsiniz, medya türlerini bilirsiniz ve web sitesi size bunların bağlantılarını sağlar. Bir REST API'si de aynı şeyi yapmalıdır. Web'i insanların REST'in yapılması gerektiğini düşündüğü şekilde tasarlasaydık, Sorular ve Cevaplara bağlantılar içeren bir ana sayfaya sahip olmak yerine, bir soruyu görüntülemek için stackoverflow.com/questions/ URI'sini almanız, id'yi Question.id ile değiştirmeniz ve bunu tarayıcınıza yapıştırmanız gerektiğini açıklayan statik bir belgeye sahip olurduk. Bu saçmalık, ancak 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 gösterimlerinde bağlantılar almıyorsa, bu REST değildir. REST'in yazarı Roy Fielding, bu blog yazısında bunu açıkça belirtmiştir: REST API'leri hiper metin odaklı olmalıdır. Yukarıdakileri aklınızda tutarak, REST'in XML ile sınırlı olmasa da, başka herhangi bir formatla 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 değildir. JSON için HAL gibi taslak standartlar vardır. Son olarak, REST herkes için değildir ve bunun bir kanıtı, çoğu insanın sorunlarını yanlışlıkla REST olarak adlandırdıkları HTTP API'leriyle çok iyi çözmeleri ve bunun ötesine asla geçmemeleridir. REST'i yapmak bazen zordur, özellikle de başlangıçta, ancak sunucu tarafında daha kolay evrim ve istemcinin değişikliklere karşı esnekliği ile zaman içinde karşılığını verir. Bir şeyin hızlı ve kolay bir şekilde yapılmasına ihtiyacınız varsa, REST'i doğru yapmakla uğraşmayın. Muhtemelen aradığınız şey bu değildir. Yıllarca hatta on yıllarca çevrimiçi kalması gereken bir şeye ihtiyacınız varsa, REST tam size göre.

RESTvsSOAP` sorulması gereken doğru soru değildir.

REST,SOAP`ın aksine bir protokol değildir.

REST, ağ tabanlı yazılım mimarileri için bir mimari stil ve bir tasarımdır.

RESTkavramları kaynak olarak adlandırılır. Bir kaynağın temsili durumsuz olmalıdır. Bazı medya türleri aracılığıyla temsil edilir. Medya türlerine örnek olarakXML,JSONveRDFverilebilir. Kaynaklar bileşenler tarafından manipüle edilir. Bileşenler, standart bir tekdüze arayüz aracılığıyla kaynakları talep eder ve manipüle eder. HTTP söz konusu olduğunda, bu arayüzGET,PUT,POST,DELETE` gibi standart HTTP işlemlerinden oluşur.

@Abdulaziz'in sorusu, REST ve HTTPnin genellikle birlikte kullanıldığı gerçeğini aydınlatıyor. Bunun başlıca nedeni HTTP'nin basitliği ve RESTful ilkeleriyle çok doğal bir şekilde eşleşmesidir.

Temel REST Prensipleri

İstemci-Sunucu İletişimi

İstemci-sunucu mimarilerinde çok belirgin bir kaygı ayrımı vardır. RESTful tarzında oluşturulmuş tüm uygulamalar da prensip olarak istemci-sunucu olmalıdır.

Devletsiz

Sunucuya yapılan her istemci talebi, durumunun tam olarak temsil edilmesini gerektirir. Sunucu, herhangi bir sunucu bağlamı veya sunucu oturum durumu kullanmadan istemci isteğini tamamen anlayabilmelidir. Bu da tüm durumun istemcide tutulması gerektiği anlamına gelir.

Önbelleklenebilir

Önbellek kısıtlamaları kullanılabilir, böylece yanıt verilerinin önbelleklenebilir veya önbelleklenemez olarak işaretlenmesi sağlanır. Önbelleğe alınabilir olarak işaretlenen herhangi bir veri, sonraki aynı talebe yanıt olarak yeniden kullanılabilir.

Tekdüzen Arayüz

Tüm bileşenler tek bir arayüz üzerinden etkileşime girmelidir. Tüm bileşen etkileşimi bu arayüz üzerinden gerçekleştiğinden, farklı hizmetlerle etkileşim çok basittir. Arayüz aynıdır! Bu aynı zamanda uygulama değişikliklerinin izolasyon içinde yapılabileceği anlamına gelir. Bu tür değişiklikler temel bileşen etkileşimini etkilemeyecektir çünkü tek tip arayüz her zaman değişmez. Bir dezavantajı, arayüze takılıp kalmış olmanızdır. Arayüzü değiştirerek belirli bir hizmete optimizasyon sağlanabilirse, REST bunu yasakladığı için şansınız yoktur. Ancak işin iyi tarafı, REST web için optimize edilmiştir, dolayısıyla HTTP üzerinden REST'in inanılmaz popülerliği!

Yukarıdaki kavramlar REST'in tanımlayıcı özelliklerini temsil eder ve REST mimarisini web hizmetleri gibi diğer mimarilerden ayırır. Bir REST hizmetinin bir web hizmeti olduğunu, ancak bir web hizmetinin mutlaka bir REST hizmeti olmadığını belirtmekte fayda vardır.

REST ve yukarıda belirtilen maddeler hakkında daha fazla bilgi için REST Tasarım İlkeleri** hakkındaki bu blog yazısına bakın.

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

SOAP (Basit Nesne Erişim Protokolü) ve REST (Temsil Durum Aktarımı) her ikisi de kendi tarzlarında güzeldir. Bu yüzden onları karşılaştırmıyorum. Bunun yerine, ne zaman REST ne zaman SOAP kullanmayı tercih ettiğimi resmetmeye çalışıyorum.

**Yük nedir?

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

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

*Aşağıda belirtilen bu iki mesajdan hangisinin daha ucuza gönderileceğini söyler misiniz?

Arin

veya

"name": "Arin"

Cevabınızın ikincisi olacağını biliyorum, ancak her ikisi de aynı mesajı temsil etse de ikincisi maliyet açısından daha ucuz.

Yani şunu söylemeye çalışıyorum: veriyi ağ üzerinden JSON formatında göndermek, yük açısından XML formatında göndermekten daha ucuzdur.

İşte REST'in SOAP'a göre ilk faydası veya avantajları. SOAP yalnızca XML'i destekler, ancak REST metin, JSON, XML vb. gibi farklı formatları destekler. Ve zaten biliyoruz ki, eğer Json kullanırsak, o zaman kesinlikle yük konusunda daha iyi bir yerde olacağız.

Şimdi, SOAP sadece XML'i desteklemektedir, ancak bunun da avantajları vardır.

**Gerçekten! Nasıl?

SOAP XML'e üç şekilde dayanır Zarf - mesajın içinde 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 toplanan yanıtların düzeni.

Bu zarf bir aktarım (HTTP/HTTPS) üzerinden gönderilir ve bir RPC (Remote Procedure Call - Uzaktan Yordam Çağrısı) çalıştırılır ve zarf XML formatlı bir belgede bilgilerle birlikte geri gönderilir.

Önemli olan nokta, SOAP'ın avantajlarından birinin "genel" aktarım kullanımı olması, ancak REST'in HTTP/HTTPS kullanmasıdır. SOAP, isteği göndermek için neredeyse tüm aktarımları kullanabilir ancak REST kullanamaz. Yani burada SOAP kullanmanın bir avantajı var.

Yukarıdaki paragrafta da belirttiğim gibi "REST HTTP/HTTPS kullanır ", bu yüzden bu kelimelerin biraz daha derinine inin.

HTTP üzerinden REST hakkında konuştuğumuzda, HTTP'ye uygulanan tüm güvenlik önlemleri devralınır ve bu taşıma seviyesi güvenliği olarak bilinir ve mesajları yalnızca telin içindeyken güvence altına alır, ancak diğer tarafa teslim ettiğinizde, verilerin işleneceği gerçek noktaya ulaşmadan önce kaç aşamadan geçmesi gerektiğini bilemezsiniz. Ve elbette, tüm bu aşamalar HTTP'den farklı bir şey kullanabilir.** Yani Rest tamamen güvenli değil, değil mi?

Ancak SOAP, tıpkı REST gibi SSL'yi destekler, ayrıca bazı kurumsal güvenlik özellikleri ekleyen WS-Security'yi de destekler. WS-Security mesajın oluşturulmasından tüketimine** kadar koruma sağlar. Bu nedenle, WS-Security kullanılarak önlenebilecek herhangi bir boşluk bulursak, taşıma seviyesi güvenliği için.

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

Ancak SOAP, hem kısa ömürlü işlemler için ACID tabanlı işlem yönetimi hem de uzun süren işlemler için telafi tabanlı işlem yönetimi için kapsamlı desteğe sahiptir. Ayrıca, dağıtılmış kaynaklar arasında iki aşamalı işlem yapmayı da destekler.

Herhangi bir sonuca varmıyorum, ancak güvenlik, işlem vb. ana kaygılar iken SOAP tabanlı web servisini tercih edeceğim.

Burada "The Java EE 6 Tutorial" Aşağıdaki koşullar karşılandığında RESTful bir tasarım uygun olabilir demişlerdir. Bir göz atın.

*Umarım cevabımı okumaktan keyif almışsınızdır.