我正要在REST中實現Web服務。
我有一個在歐洲大陸連接的巨大問題，有時會緩慢和不穩定的數據包丟失。緩慢而不穩定的互聯網連接 - SOAP vs REST
我在控制雙方，客戶端和服務器。 每秒多次執行對服務器調用的客戶端。有時它會將更多數據發送到一個連接來處理這個互聯網問題。
我讀了很多關於REST和SOAP的差異，我知道SOAP信封比REST數據大。
我的問題是，因爲兩者都是通過HTTP，有沒有性差異，除了數據大小，在兩者之間？ 你會用什麼？
正如你所暗示的那樣，它不是真正的SOAP與REST的問題，但郵件大小和消息頻率的問題。
如果協議（數目和頻率和消息的模式）可以REST和SOAP是相同的，那麼唯一的真正的區別是消息的大小。但是，真正的RESTful系統設計可能不具有與SOAP版本相同的通信模式，因爲REST涉及操作資源而不是消息到端點的方法。 REST使用一組統一的標準動詞（PUT，POST，GET，DELETE），與SOAP完全不同。如果不知道更多關於你的設計的話，很難多說。
「正確」的解決方案取決於您是否看重延遲（重點放在個人信息）或吞吐量。如果您希望每次調用成功的可能性更高（即您的延遲值），則越小越好，如果它導致更少的數據包 - 但是如果SOAP消息也相對較小，則情況可能並非如此。對於吞吐量，不管SOAP還是REST，將消息分配在一起可能會更好。
至this question的答案也可能是有用的。
最後，請注意，REST是一種體系結構，而SOAP是一種協議--REST並未指定甚至必須使用HTTP，並且它也不指定有效負載格式。因此，儘管REST實現通常具有較小的消息，但不能保證。
兩者之間的一個區別是，有一個WS-ReliableMessaging標準（由WCF實現）創建一個協議，以確保您的郵件到達並且按照正確的順序到達。如果可靠的消息傳遞（即使在有損網絡中）是一項要求，那麼這是SOAP相對於REST的巨大優勢。
SOAP接口可以製成REST風格，所以我假設你正在考慮SOAP VS簡約協議（XML或JSON，沒有ENVELOPPE）。
您指出的主要技術因素是消息的大小。 '自定義'REST爲您提供了更大的靈活性，可以根據您的需要精確設計有效負載和標題，而SOAP信封可以爲小型頻繁消息添加不重要的大小。主觀上，SOAP庫通常會引誘您依賴狀態，會話，非冪等操作或其他非RESTful模式，這對您而言將是一種責任。你總是可以拒絕這種誘惑，但它就像試圖執行無會話的JSF一樣 - 它會回到代碼的每一個角落。總的來說，我會和REST一起去。
這就是說，如果你的消息很大，並且必須交付，SOAP可能會有優勢。就我個人而言，我更喜歡「一次性客戶端，服務器和網絡」霰彈槍方法，它能夠更好地利用小型無狀態冪等和非事務性消息 - 但它使協議設計更加關鍵。