RESTFULL API中“操作”的命名约定

时间:2015-09-18 12:13:08

标签: rest naming-conventions best-in-place

我知道REST没有严格的规则,但是有一些标准化的常用做法。 我在这件事上有点新鲜。我喜欢处理集合的想法,所以我使用的是一些惯例,其中我将资源多元化,如:

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

我也喜欢嵌套集合的想法,所以我有例如:

/Messages/1/Attachments (Post/Get)

等等 但是,当涉及到发送消息等自定义操作时,我遇到了问题 一种方式:

/Messages/1/Send (POST)

但我也在想类似的事情:

/Message/1/MessageSendRequest (POST)

或者这可能是一个坏主意? 在这个例子中它适合,但在某些情况下它不适合。 如果在RESt :)中有类似的东西,最佳做法是什么?

1 个答案:

答案 0 :(得分:3)

事实上,在URL中使用“操作”并不是真正的RESTful。您应该在消息中使用状态字段。

结构类似:

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

将状态从draft更新为sending将触发发送电子邮件。您可以注意到,有两种方法可以在此地址/messages/1上执行此更新:

  • 将方法PUT与完整的有效负载一起使用。当电子邮件的内容很大时,这可能不太方便。
  • 将方法PATCH与包含要更新内容的有效内容一起使用。这里没有真正的约定。您只能发送要更新的字段({ "status": "sent" })或利用JSON PATCH格式(请参阅http://jsonpatch.com/https://tools.ietf.org/html/rfc6902),其内容如下:[ { "op": "replace", "path": "/status", "value": "sent" } ]

如果电子邮件实际上是根据请求发送的,则状态将更新为sent

另一种方法也是可能的。您可以在电子邮件网址POST上使用/messages/1方法。这将触发发送电子邮件。无需内容,如果实际发送了电子邮件,则会返回状态代码200

希望这可以帮到你, 亨利