rest - CQ(R)S 使用 RPC 风格的 API 而不是 REST

Question

我正在开发一个基于 PHP/JS 的项目，我喜欢在后端引入域驱动设计。我发现命令和查询比 CRUD 更能表达我的公共(public)领域，所以我喜欢按照 CQS 原则构建基于 HTTP 的 API。它不是安静的 CQRS，因为我想在命令和查询端使用相同的模型，但是许多原理是相同的。对于 API 文档，我使用 Swagger。

我发现一篇文章通过 REST 资源 (https://www.infoq.com/articles/rest-api-on-cqrs) 公开 CQRS。他们使用 5LMT 来区分 Swagger 不支持的命令。此外，通过将 CQS 提供的意图揭示接口(interface)放入面向资源的 REST API 中，我不会失去它的好处吗？我没有找到任何直接通过基于 HTTP 的后端公开命令和查询的文章或产品。

所以我的问题是:直接通过 API 公开命令和查询是否是个好主意。它看起来像这样:

POST /api/module1/command1
GET /api/module1/query1
...

它不会是 REST，但我看不出 REST 如何为餐 table 带来任何好处。维护 REST 资源将引入另一种模型。此外，在 URL 中包含命令和查询将允许使用路由框架和访问日志等功能。

Answer 1

命令和查询是实现细节。从以下事实可以看出这一点:如果您选择了另一种样式，它们将根本不存在。

RESTful API 通常(如果做得好)遵循概念领域模型。 概念域模型不是实现细节 ，因为它在您的用户头脑中，并且是您系统需求的来源。

因此，RESTful API 通常更容易理解，因为客户端(开发人员)无论如何都必须理解概念域模型，而 RESTful 接口(interface)遵循这种模型的概念。对于基于查询和命令的 API，情况并非如此。

所以我们有一个权衡

您已经确定了围绕命令和查询构建 RESTful API 的缺点，我指出了您的建议的缺点。我的建议如下:

如果您正在构建其他团队甚至客户使用的 API，那么请采用 RESTful 方式。 客户更容易理解您的 API。

另一方面，如果 API 只是一个内部的，例如由您的团队构建的 JS 前端使用，并且您在 API 上没有外部客户端，那么您直接公开命令和查询的建议可能是值得(上述)缺点的捷径。

如果您走捷径，请对自己诚实并承认这一点。这意味着一旦您的需求发生变化并且您现在有了外部客户端，您可能应该构建一个 RESTful API。