REST为复杂实体设计资源

Question

我有一个EF，在这里我很难根据我所拥有的ASP.Net实体来设计REST资源。

有三个实体描述了保留。首先是集团保留地：

public class GroupReservation: Entity
{
    public int Id { get; set; }
    public string? Reference { get; set; }
    public DateTime ReservationDate { get; set; }
    public bool IsQuote { get; set; }

    public int AgencyContactId { get; set; }
    public AgencyContact AgencyContact { get; set; } = null!;

    public IList<Reservation> Reservations { get; } = new List<Reservation>();
}

每个团体预订可以有多个预订：

public class Reservation: Entity
{
    public int Id { get; set; }
    public string? Name { get; set; }

    public int GroupReservationId { get; set; }
    public GroupReservation GroupReservation { get; set; } = null!;

    public IList<ReservationDetail> ReservationDetails { get; } = new List<ReservationDetail>();
}

最后，每个预订可以有多个预订详细信息：

public class ReservationDetail: Entity
{
    public int Id { get; set; }
    public DateTime ReservationDate { get; set; }
    public DateTime CheckIn { get; set; }
    public DateTime CheckOut { get; set; }
    public DateTime? FolioClosedOn { get; set; }

    public int ReservationId { get; set; }
    public Reservation Reservation { get; set; } = null!;
}

这里需要注意的是，Reservation只能存在于GroupReservation中，而ReservationDetail只能存在于Reservation中。这意味着实体不能单独存在。

在设计REST资源时，理想情况下，用户可以与单个预订对象交互。使用一个HTTP调用，用户可以创建一个带有各种保留的GroupReservation，等等。与REST一样，我试图抽象业务逻辑。

我遇到的问题是，我不知道如何实现更新请求。由于后端还有依赖于ReservationDetail的其他部分，所以不能只删除旧的实体并创建一个新的实体，因为这会破坏外键。

对于如何设计REST资源，我有很多想法。首先，我可以为每个实体创建一个子资源。这意味着对于一项保留，将有以下端点：

• /api/group预订
• /api/group_订座/预订
• /api/group_订座/保留/详细信息

然而，这不是很容易使用，也不抽象业务逻辑。理想情况下，我可以避免这种情况。我的下一个想法是创建一个模型类，如下所示：

{
  "id": int,
  "reservations": [
    {
      "id": int,
      "reservation_details": [
        "id": int
      ]
    }
  ]
}

使用此模型，可以使用一个POST请求创建整个预订，并使用PUT或修补程序请求更新现有的预订。但是，客户端必须为每个子实体指定ids。此外，如果为还不存在的ReservationDetail提供了一个id，或者缺少了一个ReservationDetail，那么应该发生什么？如果PUT请求删除相关实体可以吗？

因此，我的问题是，如何设计基于多个关系实体的REST资源而不为每个实体创建端点。

Answer 1

如何设计基于多个关系实体的REST资源，而不为每个实体创建端点。

REST资源不是数据库行，也不应该基于数据库行、实体或其他数据结构。

资源基本上是网页。您首先为每个特定的业务用例设计用户流，然后为此创建“页面”。这包括身份验证、链接、表单、导航等。

如果您这样做，数据库行和资源表示之间应该很少或根本没有连接。