如何处理REST API结构冗余？

Question

我目前正在为一个Web服务构建一个REST API，除其他外，它还处理用户禁止。

我设计的当前API看起来像：

网址：GET /user/<user_id>/bans/<session_id>

描述：获取指定用户的指定会话禁令。

输出：

{
  session_id: 1,
  banned_until: "..."
}

网址：GET /user/<user_id>/bans

描述：获取指定用户的所有禁令。

输出：

[
  {
    session_id: 1,
    banned_until: "..."
  },
  {
    session_id: 2,
    banned_until: "..."
  }
]

网址：PUT /user/<user_id>/bans/<session_id>

描述：为指定用户设置或更新指定会话的禁令。

输入：

{
  session_id: 1,
  banned_until: "..."
}

输出：

{
  session_id: 1,
  banned_until: "..."
}

现在我的一位同事认为API是错误的，因为例如在PUT的情况下，用户必须指定session_id两次：一次在URL中，一次在内容和那两个必须匹配（这意味着额外检查服务器端）。他对用户在URL中指定会话ID的GET做出相同的评论，以便将其恢复到响应中，这意味着浪费带宽。

虽然我理解他的担忧，但我认为当前的设计对于用户来说更简单（只需要关注一个数据结构），并且对服务器的额外检查并不是那么多。与它带给用户的舒适度相比。

REST最佳实践中是否有关于此的官方指南？通常/推荐的处理方法是什么？

Answer 1

就我个人而言，我认为您所讨论的是select length * breadth as T from table1; 和PUT方法之间的差异。

来自RESTful CookBook：

  

当您可以通过特定资源完全更新资源时使用PUT。例如，如果您知道文章位于http://example.org/article/1234，则可以直接通过此URL上的PUT输入本文的新资源表示。

因此，在您给出的POST示例中，我认为在URL中指定sessionID是完全有效的，因为您将禁令存储在特定点。

但是，您也可以在PUT创建POST服务，以满足您的同事。 ： - ）