REST vs SOAP evolvability

Question

我從鏈接uris中獲得好處，但這不是這個問題的關鍵。

我的意思是可拓展性是在服務中添加新功能或修改（如果可能）現有的功能，實際上就是這樣。

因爲REST社區在進化性方面傾向於談論SOAP，所以SOAP並沒有那麼糟糕。例如：

1. 在REST中，我們可以添加新的rel-in SOAP，我們可以添加新的方法。舊客戶的兩種 都將繼續使用新服務。
2. 在REST，我們可以添加新的表單字段並設置其默認值 - 在 SOAP我們可以有服務論據一些ServiceArgs類和 一個新字段添加到ServiceArgs。這是醜陋的，但它的作品。

什麼是SOAP客戶端中斷時的可演化性示例，而您對此無能爲力，而REST客戶端正在良好地處理這種情況？

謝謝！

Answer 1

SOAP是基於合同的技術。整個客戶端/服務器交互被寫在一個大文檔（WSDL）中，並且必須得到雙方的同意並且得到雙方的支持才能使其工作。如果任何一方決定添加功能，則另一方必須與其鎖定「進化」。雙方完全結合，在臀部加入，粘在一起，結婚，永遠。

增強您的SOAP服務的典型方法是爲新版本的服務創建新的WSDL文檔，同時保留舊版本。另一種技術是創建一個新接口來包含新方法並從舊方法繼承。您在＃1中描述的方法是IMO違反SOAP規則，因爲客戶端和服務器現在將使用不同的合同，並且它只能起作用，因爲添加更改（如新方法）可以在大部分時間事情會起作用。當某人做出破壞性更改時，客戶的合同將與服務器的合同不匹配，並且遊戲結束。這是一個難以管理的過程，這就是爲什麼大多數組織都選擇爲每個新版本的API創建全新的WSDL。

REST並不奇蹟般地讓所有這些問題消失，但通過不強迫您將整個分佈式系統的「合同」捆綁到一個工件中，使得管理變得更容易。你正在使用HTTP？太棒了，那麼你就可以使用Web所使用的所有美妙的HTTP功能：代理服務器，URL，內容協商，認證等。你想使用JSON編碼和XML進行通信嗎？把自己打昏。在REST中隨時都可以做到這一點，而不會影響現有的客戶端。你想要安全嗎？好吧，使用HTTP的內置支持來開始驗證認證憑證的挑戰。所有這些東西（HTTP，JSON等）都在不同的地方進行了標準化和描述，而這正是它應該如此。

SOAP將傳輸協議，位置信息，有效載荷描述，編碼選擇和RPC方法組合成一個巨大的文檔。如果您想對該列表中的任何內容進行更改，則需要一個新文檔。更糟的是，其中一些東西根本無法改變。

REST將這些內容分開，以便可以獨立演變。您的網址（或「URI」，更確切地說）會在運行時返回並假設客戶端doesn't start to hardcode them是可演化的，而無需對客戶端進行任何更改。如果您的文檔明確指出未來可能會出現新字段，則對媒體類型所做的附加更改將變得微不足道。您還可以選擇對媒體類型進行版本控制，從而允許在系統中共存v1/v2/v3 ...媒體類型，並且客戶端可以選擇（使用HTTP中的Accept和Content-Type標題）哪一個他們想要使用。

有沒有聽說過關於保時捷車主在每次菸灰缸變滿時購買全新車的笑話？這是SOAP。應該是一個微不足道的變化，需要進行重大改革。 REST爲您提供吸塵器。你不必使用它，但肯定會更便宜。