【问题标题】:CRUD Rest API related resourceCRUD Rest API 相关资源
【发布时间】:2021-03-20 17:13:46
【问题描述】:

首先,如果我的问题之前已经有人提出过,我很抱歉。但是我有google,看了一个月左右的很多文章还是不满意。

我的情况比较特殊。假设我有两个表:TicketMember 具有 1:n 的关系。我使用 React、.NET 5、Entity Framework Core 和 rest 进行通信。但特别的是我没有通过 Entity Framework Core 显式配置它的关系。这意味着在数据库中,表成员仍然有对 Ticket 的外键(ticketId)引用。但没有显示在代码中。

当我尝试创建工单时出现问题。因为票总是包含成员列表。目前我有两种方法。

  1. 定义一个类似 api/tickets 的路由并发送一个包含我需要创建的路由的所有数据的对象。例子: ticket:{id: 1, .... , members: []}
  2. 定义 2 个单独的路由 api/ticketsapi/members 并将单个数据发送到每个路由以进行创建。

第一种方法是确保数据总是同时成功或失败(我在后端使用事务来执行此操作)。但这似乎不是休息的最佳做法。 第二种方法似乎遵循最佳实践。但是,如果其中一项行动失败了,会发生什么。我不能像第一次那样回滚。

所以我的问题是我该如何处理它。这意味着我想遵循 Rest 的最佳实践,并且还需要数据完整性。我真的很感激。它对解决我当前的问题很有帮助。

【问题讨论】:

    标签: reactjs rest asp.net-core entity-framework-core


    【解决方案1】:

    会员与票证的关系可以是1:n。

    1 个成员可以有 n 张票。

    1 张票可能属于 1 个成员

    因此成员类包含票证列表。休息时,您可以定义一个端点,如 api/tickets/create ,它获取一个包含门票和成员信息的成员对象。你应该在你的rest api中处理购买票逻辑并将这个操作分成两个api不是最佳实践,只会给你的业务逻辑注入复杂性。

    【讨论】:

    • 那么处理逻辑另一个端点中的另一个资源是否很好?我认为属于一个资源的端点应该只处理该资源的逻辑。
    • 假设休息端点作为表示层。端点与您的业务逻辑或服务层无关
    • 谢谢。我会仔细考虑您的建议
    猜你喜欢
    • 1970-01-01
    • 2014-01-05
    • 1970-01-01
    • 1970-01-01
    • 2015-07-02
    • 1970-01-01
    • 2016-12-18
    • 2023-03-18
    • 1970-01-01
    相关资源
    最近更新 更多