RESTful和文檔/消息風格似乎是現在普遍實現Web服務的兩種趨勢。通過這個，我的意思是REST vs SOAP，以及文檔樣式和RPC樣式。REST適合文檔式Web服務嗎？
我的問題是如何兼容REST與文檔樣式的Web服務。從我對REST有限的知識中，它利用http GET/POST/PUT/DELETE動詞對由URL表示的遠程資源執行類似CRUD的操作，這使得它變成了一種更「健談」和遠程方法，如風格，又名RPC樣式。另一方面，文檔式Web服務強調粗粒度的調用，即發送一個批處理請求文件與複雜的信息，並期待一個響應文件也帶有複雜的信息。我看不出如何用REST很好地完成它，而沒有隻聲明一個資源用於「響應」並且始終使用POST動詞（這將打敗REST的目的）。
正如我在這兩個文檔樣式和RESTful Web服務新的，請原諒我，並親切地指出，在上述假設的任何無知。謝謝！
您對REST的理解是錯誤的。這並不奇怪，也不是你的錯。關於REST在互聯網上流傳的信息遠比有效的信息要多得多。
REST是遠更適合於粗粒文檔樣式類型的分佈式接口的比爲面向數據CRUD接口。雖然CRUD操作和HTTP GET/PUT/POST/DELETE之間存在相似之處，但這些細微差別對於應用程序的體系結構非常重要。
我不認爲你的意思是基於SOAP的REST。有可能通過SOAP做REST，但據我所知，沒有人會這麼做，我從來沒有見過一篇關於它的文章。
SOAP通常用於「Web服務」，而REST通常通過HTTP完成。
只要您認爲您的文檔是資源，REST實際上就是用於文檔。
GET允許您檢索文檔。明顯。
POST允許您創建文檔。無需您的API來需要文檔的全部內容來創建它。您需要決定實際創建文檔所需的內容。
PUT允許修改文檔。同樣，無需強制客戶在每次要保存時發送整個文檔。您的API可能支持通過PUT請求發送的增量更新。
DELETE明顯刪除文件。同樣，您可以設計您的API，以便刪除不會實際銷燬文檔的每一位。您可以創建一個類似於回收站的系統。
REST和使用文檔的好處在於服務器響應包含理解響應所需的每個信息。因此，如果創建了一個新的資源，你應該把它的位置，相同的，如果資源被移動等，所有你需要的文件是將要使用的數據類型（XML格式，JSON等）
標準HTTP方法就在那裏，因爲它們的行爲已經定義好了，只要知道URI，客戶端就可以輕鬆發現你的API。
PUT不應該做部分更新。有一項建議在作品中使用了一個新的動詞PATCH來做到這一點。在此之前，您需要使用POST和定義的支持部分更新的介質類型。 – 2009-08-10 19:16:18
感謝您的回答。這非常有幫助。在我的情況下，數據收集客戶端需要發送自己的信息，如id /上次連接時間等，以及新收集的數據。服務器的響應將包含更新的服務器數據/配置。由於我希望在單個REST調用中完成任務，因此它看起來唯一可行的動詞是POST，因爲我在請求和響應中都有有效載荷數據。你認爲這是使用REST的正確方式嗎？ – hongliang 2009-08-10 19:40:34
（繼續上面的評論，由於600字符的限制）在我看來，「更多RESTful的選擇是使用兩個調用：一個POST請求，然後是一個」GET「響應，但它確實感覺不對，另外，我確實需要將每個響應文檔與相應的請求文檔關聯起來 – hongliang 2009-08-10 19:43:59
非常感謝您的回答。我很高興知道這兩者確實可以一起工作，但仍不確定我應該如何去實施它。能否詳細說明「REST更適合粗粒度文檔風格類型的分佈式界面」的原因？指出一個簡單的例子或在互聯網上的少數有效信息將不勝感激。 通過「REST over SOAP」，我的意思是說「REST優於SOAP」。我只是編輯我的帖子，以避免混淆。我錯誤地認爲REST與SOAP相同，因此可以替代SOAP？ – hongliang 2009-08-10 18:25:31
關於SOAP和REST是否在同一層，看到這個答案我給了一個類似的問題http://stackoverflow.com/questions/1225701/well-behaving-restful-client-interactions/1230610#1230610 – 2009-08-10 20:07:42
謝謝。我發現下面的句子特別有啓發性：「Web服務提供要由客戶端應用程序處理的數據，RESTful接口應該提供將呈現給用戶的內容。」由於我的界面實際上是爲了在服務器和客戶端應用程序之間同步應用程序信息而不將它呈現給用戶，我可能應該使用Web Service方法。 – hongliang 2009-08-10 23:05:58