The API handles bookings in a different manner to other resources - this is because of the way that bookings cross-cut the other resources. Consequently, bookings are not accessed directly, rather they are manipulated via other resources.
Warning
All front-end requests use the branch resource to manipulate bookings and as such, all testing has been against that resource. There may be dragons waiting in other parts of the API that are less well tested for booking manipulation.
Creating a booking is a simple POST operation. If the user has admin or keaz privileges, additional fields may be submitted in the request body.
Operation: POST /vehicle/1/booking/DATETIMEPATH
Request body:
{
"user-id": 3,
"cost-centre_id": 7,
"trip_purpose": "service"
}
Intent: create a new booking
Status: 201 Created
Response body: { BOOKING HASH }
Note
Newly created bookings will send an email to either the approval users or the user who made the booking.
Bookings which require approval will be assigned a ticket. This ticket can be submitted with a PUT request in order to move the booking status from pending to approved.
Operation: PUT /booking/approve/TICKET
Intent: approve booking
Status: 200 OK
When a booking is returned, it includes constructed related data and the start and end times as follows
Operation: GET /booking/1
Intent: fetch booking 1
Status: 200 OK
Response body:
{
"id": 1,
"user_id": 2,
"company_id": 7,
"cost-centre_id": 3,
"branch_id": 13,
"vehicle_id": 81,
"vehicle_name": "gi joe",
"vehicle-body_id": 2,
"vehicle-model_id": 6,
"createdby_userid": 1,
"date_created": { DATETIME },
"start": { EPOCH },
"end": { EPOCH },
"start_string": { DATETIME },
"end_string": { DATETIME},
"trip_purpose": "joyride",
"state": "approved",
"cost_total": "0.0",
"cost_type": ?,
"cost_sub": ?,
"cost_time": ?,
"cost_currency": "aud",
"company": { COMPANY HASH },
"branch": { BRANCH HASH },
"cost-centre": { COST-CENTRE HASH },
"user": { USER HASH },
"vehicle": { VEHICLE HASH },
"vehicle_assets": { ASSETS HASH }
}