Can reserve flight without passengers / Can't add passengers anymore after flight is reserved

[J-C-V]

Endpoint

flights/reservation flights/booking

Method

POST

Description

I'm able to reserve a flight without passengers.

Hence I can't book the flight anymore because I dont have any passengers for that flight.

So I would think I can add them with a subsequently request. But that is not the case:

flights/reservation

flights/booking

Steps to reproduce

See description.

Expected behaviour:

Either I get an error during flight reservation or I can add Passengers afterwards.

[MetaEMK]

Do you want to force all passenger data to be entered when a reservation is made? Alternatively, we can add an action type that specifies whether the object (passenger) should be added, deleted, or modified.

Should a flight reservation without any passenger be possible?

[J-C-V]

I think we should rethink the current booking process. In hindsight PLANNED seems kinda useless? Wouldn't it be easier if we just use RESERVED -> BOOKED like initially planned? For arguments sake let's look at this scenario:

RESERVED

• A RESERVED flight is partially immutable.
• An open flight needs to have following properties so that it can be set to RESERVED:
  • Departure time
  • Plane
• Passengers / Pilot can be added when a flight slot gets set to RESERVED or aftwards while still being RESERVED

BOOKED

• A BOOKED flight is immutable (except special case admin privileges)
• A RESERVED flight needs to have following properties so that it can be set to BOOKED:
  • Departure time
  • Plane
  • Pilot
  • Passengers

Isn't the whole point of RESERVED to just block that slot, so that no other salesperson can take it? Currently PLANNED is RESERVED just without passengers. Thinking about it I think this adds just unnecessary complexity.

Mabye I'm missing something.

[J-C-V]

A possible Mock-API could look like this (open for discussion):

POST /flights

{
    "PlaneId": number,
    "DepartureTime": Date,
    "ArrivalTime": Date | null,
    "Description": string | null,
    "Passengers": Passenger[] | null
}

This creates the flight entity and automatically sets the status to RESERVED. Passengers can be created during this step as well.

PATCH /flights/:id

{
    "Status": "BOOKED" | null,
    "ArrivalTime": Date | null,
    "Description": string | null,
    "Passengers": Passenger[] | null
}

BOOKED can be set at any time while the flight is still being set to RESERVED. While being set to RESERVED you freely can adjust ArrivalTime, Description and Passengers as well. The backend has to validate if those adjustements make sense and throw an error accordingly. Again the whole point of RESERVED is just to block that flight slot.

When the status is set to BOOKED the backend must throw an error if no passengers are present in the database or if no passengers are specified in the BOOKED request.

With this we would be kinda RESTful again as well, but probably increases the complexity in the backend?

Another idea would be to keep those described endpoints with the exception to not be able to set the Status in the PATCH request. The PATCH request is soley for adjustemnts during reservation.

To book the flight you would then simply make a request to POST /flights/:id/book with no additional data. The endpoint pretty much just validates the existing data in the database and sets the status to BOOKED and throws an error in case something is missing. In that case adjustments have to be made with the PATCH /flights/:id endpoint.

This is of course not RESTful.

In all cases passengers get fully replaced by the request data. To remove all passengers an empty array has to be sent.

The PATCH endpoint might semantically be a POST endpoint as well - but I would've to look up the POST and PATCH specification again...

[MetaEMK]

impl. in v0.2.1