我已經使用了RPC多年，但現在我們必須使用REST。我試圖理解兩者之間的差異，以及一個人如何優於另一個人。因此，我閱讀了大量試圖充分理解這些微妙之處的文章。到目前爲止，這看起來不錯，但有一些小問題。將RPC接口轉換爲REST
我明白（至少我認爲我是這樣做的），將事物分享爲通過使用動詞GET，PUT等獲得的資源的一般想法。這很好地映射到大多數服務器訪問概念，但有其他想法不容易映射。例如，我需要通知服務器下載一張gravatar圖像並存儲它。我不確定這是如何適合RESTful端點的。
請注意，我知道如何做RPC僞裝成REST，但我對此不感興趣。如果沒有其他理由而不是理解這種方式實際上是什麼，我想以「休閒方式」來做到這一點。
是的，在大多數情況下，RPC風格的服務可以很好地映射到REST。所以，CRUD操作映射到任何地方都很好。無論如何，我們可以在第一階段確定契約方法將它們映射到URI和不同的HTTP動詞。第二階段是引入資源，可能是它們以DTO對象的形式出現。從RPC
反正路線圖，以REST（最有可能的2級）好於理查德森成熟度模型描述（RMM）：
級別0： SOAP，XML RPC，POX，單一URI
1級： URI隧道，很多的URI，單動詞
等級2：許多URI，許多動詞，CRUD服務（例如亞馬遜S3）
3級： 2級+超媒體RESTful服務
更多關於RMM這裏：
http://code.google.com/p/implementing-rest/wiki/RMM http://martinfowler.com/articles/richardsonMaturityModel.html
但在我看來，你已經知道那。那麼複雜的情況呢。有很多。以問題爲例：
例如，我需要通知服務器下載一個gravatar圖像 並存儲它。我不確定這是如何適合RESTful端點的。
我不認爲它很難映射到REST。一切都取決於細微差別。作爲例子，爲什麼在用戶選擇「gravatar」選項時註冊用戶時不這樣做。或者爲什麼不有GET http://bookslirarysample.com/users/15/gravatar。這對REST來說不是問題。
但也許你不僅假設REST端點或如何說服務器。當然，在gravatar下，功能不僅僅是REST調用。在服務器上可能是消息總線，您的REST服務器通過它發送消息。特殊的「下載器」服務將收到此消息，下載圖像，將其存儲並保存到帶有某個標識的用戶對象。 REST並不是否定它背後的巨大服務器infrusturuture。REST幕後可能是複雜的企業級事件驅動架構。對於REST來說這不是問題。
無論如何有更先進的方案。例如通知聚合，交易，安全等許多，在吉姆·韋伯的書很好的描述：
你問究竟是什麼 - 如何實現使用REST添加的Gravatar圖像用戶資料？ – Regfor
不，我更一般地詢問如何在REST中表示不會輕易映射到典型GET，PUT等語言的過程。 –