CRUD RESTful API 中的业务逻辑答案

【问题标题】：Business Logic in CRUD RESTful APICRUD RESTful API 中的业务逻辑
【发布时间】：2015-11-10 17:08:27
【问题描述】：

总结

我想阻止被标记为垃圾邮件发送者的用户在我的应用程序上发送消息。消息 API 是否应该验证发送用户不是垃圾邮件发送者（从而返回 400）？还是调用者的责任？

有几个应用程序和一个网站使用 CRUD RESTful API，其中有两个，一个用于用户，一个用于消息传递。

争论的是消息 API 的调用者是否负责验证用户的垃圾邮件状态。

想法？

【问题讨论】：

【解决方案1】：

您可以考虑第三种选择。你写道：

呼叫者通常已经拥有可用的用户配置文件。

您可以要求每个 Message API 请求都包含用户配置文件。然后，Message API 可以在不调用 User API 的情况下检测垃圾邮件发送者。

优点：

缺点：

我并不是说这个选项是最好的，它只是另一个需要考虑的候选者。哪个选项最好取决于每个赞成和反对论点的权重。您和您的团队成员应该判断哪些方面对您的组织和您的具体情况最重要。

【讨论】：

我实际上一直在想一个好的折衷方案。除了整个用户配置文件，我还可以只需要一个参数“is_spammer”。这将迫使调用者要么找到正确的事情并进行查找，要么有意识地做错事情。

【解决方案2】：

业务逻辑总是使服务混乱。有些人通过将业务服务与基础设施/数据服务分开来解决这个问题。不幸的是，当单个基础设施数据服务导致许多业务服务发生变化时，这似乎会使事情变得更加复杂。

不要分发您的业务逻辑。保持服务“干净”是不值得的。这种“干净”的实现是虚构的。您已经与其他服务有很多耦合，只是您没有那样想它们。我保证您的消息传递依赖于 SMTP 或 MQ 服务。它们只是不是您编写的服务。

我将封装您对用户服务的访问，就像您对任何其他数据访问（如数据库）一样。将其包装在 DAO 或存储库模式中。此时，您可以评估您是否遇到了性能问题，如果是，请为您的用户实施一个缓存层来解决它。

【讨论】：