ServiceStack，REST和多個參數

想象我有一個用來添加銀行卡上執行的操作的WCF web服務。問題是有大約30個不同的參數在WS上傳遞。

在WCF上很容易做到，用所有這些參數調用一個RPC。

問題是我想將此WCF WS切換到帶有ServiceStack的REST API。

我遇到的問題是，如果我嘗試使用REST創建操作並通過'querystring'傳遞參數，我有一個字符串，非常適合閱讀和非常非常長（?amount=1234&operationID=12&等）。

我知道這種做法並不好，因爲它不是資源導向的，但是我的意思是我應該將該項目的創建拆分爲幾個步驟（我的意思是，首先使用POST創建，然後使用POST添加新的信息/字段幾個職位？）。

在這種情況下，我看不清REST的增益。

2013-01-09 kilroyFR

最後一段聽起來像是想使用GET來創建資源。正如@Kevin Junghans指出的那樣，如果你正在創建一些東西，那麼這部分應該在POST操作中完成。應該保留GET來檢索數據。 – ThatBlairGuy

如果您將這些參數傳遞給查詢字符串，我假設您正在執行HTTP GET。在REST API中，GET通常保留用於獲取數據，並且您傳遞的唯一參數是篩選結果。如果您正在執行更改要執行POST或PUT的系統狀態的操作，並將消息正文中的數據作爲XML或JSON傳遞，而不是在查詢字符串中傳遞。

與REST的增益是，如果你打開此API起來，其他的，因爲它使得它更移植到異構系統也有一些性能優勢。它還會打開您的API，以供客戶端（如Web瀏覽器）使用。但是，如果這個API僅用於.NET應用程序的內部使用，而不是在瀏覽器中運行，那麼您可能想要堅持使用WCF。 REST不是每個問題的答案。

2013-01-09 21:33:46

你的第一段我完全同意，但第二段沒有那麼多。除了公共便攜性之外，REST還有其他優勢。即使這僅用於內部使用，其他團隊成員甚至跨部門都可以輕鬆訪問Web服務，因此具有價值。 –

protonfish - 但是如果團隊的其他成員仍在使用.NET，並且客戶端不是瀏覽器，那麼使用VS發現Web服務，創建代理以及處理序列化和反序列化只需點擊幾下即可完成對象。使用REST，這是一個手動過程，需要更多時間來開發客戶端，而版本控制難以處理。其他的收益會抵消這一點？ –

我很懷疑VS是你聲稱的所有魔法。但是我知道REST的工作原理並不是平臺特定的。REST（正確完成）是可發現的，JSON很容易跨平臺使用。此外，HTTP是一種客戶端 - 服務器協議 - 如果您創建主要由其他服務器使用的API，我會查看消息排隊協議或通過公開的存儲過程直接訪問數據庫。 –

我不確定要理解您的問題... REST並不意味着「無負載」。相反，REST的意思是「表徵狀態轉移」，所以HTTP請求的主體（又名「表徵狀態」）是至關重要的。

由於很多原因，在銀行的情況下，資源通常是銀行業務。 CouchDB的指南有一個非常不錯的scenario about that。

換句話說，你的「參數」將資源表示的屬性（在JSON，XML或你想要的），你會GET，POST，PUT或DELETE。

2013-01-09 21:22:57

回答