REST + hacks/REST + RPC混合。我做得对吗？

Question

TL；博士如何将SPA中的REST请求与一些非REST请求混合(前端/后端)？或者我只是休息的不对？

我们正在为SPA和手机(可能还有一些第三方)计划新的API。我想，会有一些要求不能被休息所涵盖。

我说的主要是一些请求，这些请求会使后端做一些事情，这些请求会根据文档修改文档的状态或提供一些附加信息，但是请求本身相当简单。

这里是一个很简单的例子。我想在博客文章中添加一个评论。例如，我可能会这样做：

1. 创建评论。POST /comment
2. 在作者和注释之间创建连接。POST /comment_author或PUT /comment与author_id。
3. 在注释和post之间创建连接。POST /comment_post或PUT /comment与post_id。

我也可以在POST /comment中使用{author_id, post_id}这样的操作，这在这里看起来是最符合逻辑的。

所有的东西都起作用了，评论被添加到博客中并与作者联系在一起。

现在客户想要得到他的评论的统计数据，像文字统计和字母统计。作为请求的一部分，我传递comment_id。后端可能会更新带有stats数据的注释，它可能会创建单独的实体并将其与注释链接起来，或者它可能只为这个注释发送那些状态而不保存。

那么选择是什么呢？

我可以做这样的事情：

• GET/PUT /comment/:id/stats。对我来说，它似乎已经黑了，因为结果我不想要一个注释类型的文档，而是不同类型的文档。此外，我不发送请求的统计数据，我在后端计算它们，所以使用PUT似乎是错误的。
• POST/GET /comment_stats/:comment_id。看起来是合法的，但是如果我没有一个comment_stats类型的文档/实体，这意味着我实际上要求后端创建一些东西，后端会回复我OK/Created，但实际上我没有保存这个文档。

因此，虽然我理解REST != CRUD，但我认为对于简单的CRUD使用REST，对于这种情况则使用RPC。所以在RPC场景中，我只需要调用POST comment.stats(comment_id)

我的问题是，在这种情况下，什么是更好的选择，以及我对rest/rpc的想法是对的？

Answer 1

为了正确地分离关注点，我将使用GET /comment_stats/:comment_id，这样报告代码就不会干扰comment资源。

如果您实际上没有一个comment_stats文档，或者数据是如何在后端表示的，这并不重要。REST只是后端的一个抽象。

一般来说，对于任何像这样的非CRUD操作，最好是创建一个新的资源，并像处理“机器”一样处理它:您向机器发送一些指令(通过GET或POST调用)。机器执行它，然后返回结果。一个简单的例子是转换图像的端点:您创建一个/image_converter端点(机器)，将一个图像发送给它，它将其转换，并将图像发回。/image_converter在数据库中没有关联的实体/文档，但是对于最终用户来说，它仍然是一个具有逻辑行为的资源。