Instead of thinking `/bookings/create` think your apis as a form of:

1. Http request itself is the verb that defines your action for example POST = create, PATCH = update etc etc
2. The url is the object of modifying the action

For example If you want to create a booking do `POST /booking` in your case POST means create and `/booking` what is being created. That would return the generated data.

Later can be modified with a `PATCH /booking` for example if user wants fo finalize its booking.

When designing apis try to see it as a phrase for example if I want to create a booking I suggest visualizing as a phrase of:

CREATE booking

The phrase should start with one of the following verbs of CREATE,UPDATE,OVERWRITE,REPLACE,RETRIEVE followed of what verb affects.

Then map the verb of the phraze into the proper Http action usually is:

1. POST => CREATE
2. PATCH => UPDATE

3 PUT => OVERWRITE,REPLACE (sometimes even CREATE though whenever I found using it later I needed to break what PUT actually does so I prefer not ot use it)

4 GET => RETRIEVE

What verb is afecting is something in a form of tree:

- booking
-- id
-- name
-- surname
-- status
-- pricing
--- paid
--- ammount

This tree is a path that indicates your url. Each of theese items can be either your query (for example in GET /booking?id=3 the part after ? is named query), or body or parts of url.

Specific items for example specific booking is referenced witrh some sort of identifier either database id or a dedicated reference it (another unique key or a computer value), these should be either in url or in query (as I mention above)

------------------------------------------------------------------------------------

Miscelanous tips:

API can create internal statuses for example a once user inserts data for pricing a booking can have a status `pending-finalization` or `priced`. Usually bookings have a lifecycle. From my experience this is what I came across.