對建模行爲/概念不熟悉的建議

我在尋找有關REST-ify行爲/概念的最佳方法的相關建議和經驗，這些行爲/概念不是「常見的」 - 換句話說，資源 - 轉換或副作用行爲。對建模行爲/概念不熟悉的建議

首先，讓我說，我知道沒有完整的測試REST-fulness - 實際上我不在乎。我發現REST的CRUD-over-the-Web概念非常直觀，並且在我提供的大多數數據上都能很好地工作。與此同時，我並不擔心從任何人的聖經中如何完美地休息 - 如果有什麼東西。我在尋找實際和REST之間的最佳折衷 - 直觀的是對於那些不適合的案例。顯然，一致性是主要目標，但直覺性有助於確保這一點。

鑑於此，讓我深入瞭解我所追求的細節。因爲REST本質上是資源導向的，所以很容易對通常持續存在的事物進行建模 - 不太清楚的是如何模擬不常見的行爲/概念，特別是那些有副作用或純粹是變革性的行爲/概念。

例如，拿一個stackoverflow.com問題。它可以被創建，更新，閱讀和刪除。每個人都可以涉及到這一點，在REST下這一切都很有意義。

但現在考慮類似翻譯 - 例如，我想爲我的服務構建一個REST API，將英語句子翻譯爲西班牙語。

至少有兩種方法可以解決翻譯情況。我可以：

看翻譯調用作爲創建一個「翻譯實例」（這不會發生在被保留的，但可能是），在這種情況下，POST /轉換（即創造）實際上很有意義。如果翻譯服務需要翻譯某個網址（因爲該網址的內容可能隨時間而改變），情況尤其如此。
把翻譯視爲真正的查詢更大的已知答案字典的行爲，在這種情況下GET/Translation（即讀取）可能更合適。如果翻譯服務只需要翻譯句子的文本，這是特別誘人的。沒有人會期望靜態句子的翻譯會隨着時間而改變。你也可以爭辯說它可以被緩存，GET會適應它。

此相同的困境可以裁剪彌補其主要有副作用其它動作（例如，發送SMS或電子郵件），並且較不常見的數據的持久性相關聯。

我到目前爲止的做法基本上是「訂購」這些案件，即查看所有情況，就好像一個訂單一樣。更一般地說，我認爲這只是將動詞（翻譯）轉換成名詞（翻譯順序），這似乎是REST的一種方式 - 如果這樣的話。

任何人都可以分享一個更好，更直觀的方法來處理通常假定不會持續的動作/行爲的建模嗎？

來源

2011-01-06 kvista

「不止一次會傷害嗎？」 - 也許測試？

在你的例子中 - 如果你被要求翻譯相同的文本兩次會發生什麼？不是很多。發送短信兩次可能是一件壞事。

來源

2011-01-06 20:10:40 villintehaspam

感謝您的建議。我同意這有時是一個有用的測試。然而，正如我所提到的，如果我將網址傳遞給網頁進行翻譯，那麼是的 - 執行兩次可能會產生不同的結果（例如，在發出請求的時候頁面發生了變化），所以我猜這取決於服務的細節。 – kvista 2011-01-06 21:37:12

生成不同的結果不一定是反對使用GET的原因 - 畢竟，在更改的頁面上的GET也會這樣做。這就是爲什麼我們有Last-Modified和Expires。 GET-GET-GET-GET的辯論更多的是副作用而不是可複製性本身 – telent 2011-01-07 14:35:10

您描述的兩個選項是有效的選項，當一個比另一個更好時，您已經強調了場景。唯一的其他選項，我會建議使用POST與「處理資源」。例如

POST /translator?from=en&to=fr 
Content-Type: text/plain 
Body: The sentence to be translated 
=> 
200 OK 
La phrase à traduire

「處理資源」的一個好處是它們可能會或可能不會產生持久的副作用。顯然，缺點是中間商無法緩存響應。

來源

2011-01-06 20:18:53

對建模行爲/概念不熟悉的建議

回答

相關問題