對問題的REST API

「操作」命名約定我知道REST有沒有嚴格的規定，但也有它的標準化共同做法。我在這件事上有點新鮮。我喜歡上一個收藏工作，所以我使用了一個約定在這裏我以複數等資源的想法：對問題的REST API

/Messages (POST/GET/) 
/Messages/1 (DELETE/PUT)

我也喜歡築巢收藏的想法，所以我有，例如：

/Messages/1/Attachments (Post/Get)

等但我有一個問題，當涉及到自定義操作，如發送消息一個方式，它是：

/Messages/1/Send (POST)

，但我在想ALS g就像這樣：

/Message/1/MessageSendRequest (POST)

或者這可能是一個壞主意？在這個例子中它適合，但在某些情況下不適用。什麼是最好的做法，如果有這樣的事情在休息:)

2015-09-18 bunny1985

事實上，使用「動作」到網址是不是真的REST風格。您應該在消息中使用狀態字段。

類似的東西的結構：

{ 
    "id": "1", 
    "title": "some content", 
    "date": "...", 
    "status": "draft", 
    (...) 
}

從draft到sending更新狀態會觸發電子郵件的發送。你可以看到，有兩種方法可以做到這個地址/messages/1此更新：

使用方法PUT與完整的有效載荷。當電子郵件的內容很大時，這可能不太方便。
使用包含要更新什麼有效載荷的方法PATCH。這裏沒有真正的約定。 [ { "op": "replace", "path": "/status", "value": "sent" } ]：你可以用這樣的內容只發送字段更新（{ "status": "sent" }）或充分利用JSON補丁格式（見http://jsonpatch.com/和https://tools.ietf.org/html/rfc6902）。

如果電子郵件實際上是根據請求發送的，則狀態將更新爲sent。

另一種方法也是可能的。您可以在電子郵件地址/messages/1上使用方法POST。這將觸發發送電子郵件。沒有內容將是必要的，如果電子郵件實際發送，將返回狀態代碼200。

希望這可以幫到你， Thierry

2015-09-18 15:36:08

回答