CRUD RESTful API中的业务逻辑

Question

摘要

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

架构：

细节

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

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

使用Messaging API进行验证的优点：

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

进行验证的Messaging API的缺点：

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

有什么想法吗？

Answer 1

您可以考虑第三个选择。 你写了：

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

您可以要求每个Message API请求都包括用户个人资料。 然后，Message API可以检测垃圾邮件发送者而无需调用User API。

优点：

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

缺点：

• 客户端必须始终将每个请求中的用户配置文件发送给Message API（实现起来比较复杂，Message API请求被与请求目的不直接相关的数据污染）
• 尚无用户配置文件的客户端，必须对用户API执行额外的请求。

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

Answer 2

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

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

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