Question

我正在尝试找出API设计的最佳或通用做法。我主要担心的是：

POST /users/:id/reset_password

在我看来，此端点可以用于多种功能。我会用它来更改用户名或个人资料，但是例如，重设密码呢？

从“模型”的角度来看，它可以是标志，即用户的属性，因此发送修改将“工作”。

但是我希望更多类似的东西

POST /users/:id/enable
POST /users/:id/birthday
...

但这意味着几乎每个修改我都可以根据修改的含义创建一个不同的端点，即

GET /user/:id/birthday

甚至

GET /users/:id

相比简单

    /**
    * @Route("/api/product/update", name="product_udpate", methods = {"PUT"})
    */

因此，基本上我不知道何时停止使用单个POST / GET和创建不同的端点。

在我看来，这只是一个简单的选择，我只想知道是否有某种标准的方法或准则。阅读并查看示例后，我仍然不确定。

Answer 1

免责声明：在很多情况下，当人们真正想要的是具有漂亮URL的HTTP兼容RPC设计时，人们就会对REST产生疑问。接下来，我要回答关于REST的问题。

在我看来，此端点可以用于多种功能。我会用它来更改用户名或个人资料，但是例如，重设密码呢？

当然，为什么不呢？

我不知道何时停止使用单个POST / GET并创建不同的端点。

一个很好的起点是吉姆·韦伯（Jim Webber）的演讲Domain Driven Design for RESTful systems。

第一个主要想法-您的资源不是您的域模型实体。 REST API实际上是域模型前面的立面，它支持您只是一个网站的错觉。

因此，您的资源类似于代表信息的文档。 URI标识文档。

第二个主要思想-客户端使用URI来缓存资源的表示形式，因此我们不需要一直将请求发送回服务器。相反，我们为HTTP communicating caching meta data从服务器到客户端建立了许多标准方式。

关键是the rule for cache invalidation：成功的不安全请求会使先前缓存的相同资源（即相同URI）的表示形式无效。

因此，一般规则是，如果客户端要执行某些操作来修改他们已经缓存的资源，那么我们希望修改请求转到相同的URI。

您的REST API是使您的域模型看起来像网站的外观。因此，如果我们考虑如何构建一个网站来做同样的事情，它可以为我们提供有关如何安排资源的见解。

因此，为了借用您的示例，我们可能具有用户的网页表示形式。如果我们要允许客户修改该页面，那么我们可能会考虑一堆用例（启用，更改生日，更改名称，重置密码）。对于每种受支持的案例，我们都有指向特定任务表格的链接。这些表单中的每一个都有允许客户描述更改的字段，以及表单操作中的url，用于确定表单的提交位置。

由于客户端要实现的目的是修改个人资料页面本身，因此我们希望每个表单都将 back提交回个人资料页面URI ，以便客户端知道使如果请求成功，则先前缓存的表示形式。

因此您的资源标识符可能类似于：

/users/:id 

/users/:id/forms/enable
/users/:id/forms/changeName
/users/:id/forms/changeBirthday
/users/:id/forms/resetPassword

每个表单将其信息提交到/users/:id的位置。

那确实意味着，在您的实现中，您可能最终将有许多不同的请求被路由到同一处理程序，因此您可能需要在那里消除它们的歧义。

用于资源修改的REST API设计：捕获所有POST与多个端点

1 个答案: