Now we’re at the stage where we can start to plan out our API.
We’re going to have thee distinct ways users interact with the service: a site admin, a hotel employee and a hotel guest.
As a software architect, at this stage we need to ask ourselves: "What are all the things each of these user types need to be able to do?"
Let’s run through it.
Site Admin
- Create, View, Update and Delete Any Record for both Hotels and Guests
Hotels
- CRUD new properties
- CRUD new room types
- CRUD room types
- CRUD room pricing and availability
- RUD reservations
- R transactions
- reverse charges
"CRUD" is shorthand for Create, Read, Update and Delete.
Guests
- View Listings with Feature Complete Search Functionality
- Book Stays, Using Apple Pay, PayPal or Manual Entry
- Chat with the hotel
- Get contact, directions and important information
Our business goal is to charge hotels a monthly subscription fee based. saas-product makes that easy, so for now we’re going to only focus on a free tier that includes unlimited bookings.
Let’s start with defining the endpoints for the Guest Frontend
listings/search
listings/book
property/chat
property/info
For the search functionality, we’re going to need to decide on some minimum input keys. At a minimum we need the starting date, number of nights and the GPS coordinates of the searcher or a city name to search in. Every other field will be optional.
For the booking functionality, we’re going to need Registered Guest information, a reservation confirmation. A reservation confirmation is going to need a transaction_id, if pre-paid, dates and the specifics of which room was booked.