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

Posted 2023-02-16

【中文标题】REST API + hacks/REST + RPC 混合。我做对了吗？

【英文标题】：REST API + hacks/REST + RPC hybrid. Do I get it right?

【发布时间】：2016-09-09 15:02:35

【问题描述】：

TL;DR 如何在 SPA（前端/后端）中混合 REST 请求和一些非 REST 请求？还是我只是弄错了 REST？

我们正在为 SPA 和手机（可能还有一些第三方）计划新的 API。我想会有一些请求不能被 REST 覆盖。

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

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

创建评论。 POST /comment 在作者和评论之间建立联系。 POST /comment_author 或 PUT /comment 与 author_id。 在评论和帖子之间建立联系。 POST /comment_post 或 PUT /comment 与 post_id。

我也可以用author_id, post_id 做类似POST /comment 之类的事情，这实际上在这里看起来最合乎逻辑。

一切正常，评论添加到博文并与作者相关联。

现在客户想要获取他的评论的统计信息，例如单词统计信息和字母统计信息。作为请求的一部分，我通过comment_id。后端可能会使用统计数据更新评论，它可能会创建单独的实体并将其与评论链接，或者它可能只是将这些评论的统计信息发送给我而不保存。

那么会有哪些选择呢？

我可以这样做：

GET/PUT /comment/:id/stats。对我来说，它似乎已经破解了，因为结果我不想要评论类型的文档，而是不同类型的文档。除了我不通过请求发送统计信息外，我还在后端计算它们，因此使用 PUT 似乎是错误的。 POST/GET /comment_stats/:comment_id。似乎合法，但如果我没有comment_stats 类型的文档/实体，这意味着我实际上要求后端创建一些东西，后端会回复我OK/Created，但实际上我没有将这个文档保存在某个地方。

所以，虽然我了解 REST != CRUD，但我想将 REST 用于简单的 CRUD，并且对于类似的情况，使用 RPC。所以在 RPC 场景中，我只需要调用 POST comment.stats(comment_id)

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

【参考方案1】：

我会使用GET /comment_stats/:comment_id 来适当分离关注点，这样报告代码就不会弄乱comment 资源。

如果您实际上没有comment_stats 文档，或者数据在后端的表示方式，都没有关系。 REST API 只是后端的抽象。

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