CRUD RESTful API中的业务逻辑

Question

摘要

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

架构：

详细

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

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

执行验证的Messaging API的优点：

• 统一实施业务逻辑。未来的消费者不会忘记执行它。
• 维护也更容易，一个地方不是三个。

进行验证的消息传递API：

• 缺点是验证需要从Messaging API调用到有臭味的User API。
• 这也很慢，并且每次POST到Messaging API都会增加开销。呼叫者通常已经拥有用户配置文件。
• 到目前为止，还有一个非常简单和干净的API实现方式。

思想？

Answer 1

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

  

来电者通常已经拥有用户个人资料。

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

优点：

• 统一执行业务逻辑。
• 维护更容易：一个地方，而不是三个。
• 消息API和用户API保持断开状态。
• 消息API性能不会受到太大影响。

缺点：

• 客户端必须始终将每个请求中的用户配置文件发送到Message API（实现起来更复杂，消息API请求受到与请求目的无直接关系的数据的污染）
• 尚未拥有用户个人资料的客户端必须对User API执行额外请求。

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

Answer 2

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

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

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