0

I have an ASP.Net Core Web API where I am having difficulties designing the REST resources based on the EF Entities I have.

There are three entities that describe a Reservation. First, there is the Group Reservation:

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>();
}

Every Group Reservation can have multiple Reservations:

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>();
}

Finally, every Reservation can have multiple Reservation Details:

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!;
}

Important to note here is that a Reservation can only exist in a GroupReservation and the ReservationDetail can only live in a Reservation. This means the entities can not exist on their own.

When designing the REST Resources, ideally, the user could interact with a single Reservation object. With one HTTP call, the user could create a GroupReservation with various Reservations, etc. As it is usual with REST APIs, I'm trying to abstract the business logic.

The problem I am having is that I don't know how I could implement Update requests. Since I have other parts in the backend that rely on a ReservationDetail, I cannot just delete the old entity and create a new one, as this would break the foreign key.

I had various ideas on how to design the REST resource. First, I could create a subresource for every entity. This means for a reservation, there would be the following endpoints:

  • /api/group_reservation
  • /api/group_reservation/reservation
  • /api/group_reservation/reservation/detail

However, this isn't very pleasant to use and does not abstract business logic. Ideally, I could avoid this. The next idea I had was to create a model class that would look like the following:

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

With this model, one could create an entire reservation with one POST request and update an existing reservation with a PUT or PATCH request. However, the client would have to specify the ids for every sub-entity. Moreover, what should happen if an id is provided for a ReservationDetail that does not exist yet, or a ReservationDetail is missing? Is it ok if a PUT request deletes a related entity?

Therefore, my question is, how should one design REST resources based on multiple relational entities without creating endpoints for every single entity.

1 Answer 1

0

how should one design REST resources based on multiple relational entities without creating endpoints for every single entity.

You shouldn't. REST resources are not database rows and shouldn't be based on database rows, entities or other data structures.

Resources are basically web pages. You design the user flow first for every specific business use-case you have, and then create the "pages" for that. This includes authentication, links, forms, navigation, etc.

If you go this way, there should be very little to no connection between database rows and resource representations.

2
  • Usually, the easiest way to update such objects is to delete child entities and recreate them. How would I create PATCH/PUT requests if I can not delete child entities because of existing relations they may have? Jul 22 at 10:22
  • @J.Paravicini Use a document db, an ORM, or hand write your update logic.
    – Rik D
    Jul 22 at 11:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.