How NOT to design APIs
I was helping out a friend who needed to integrate housing availability from a property management system with his client’s website. Luckily, the property management system had an API. Unfortunately, everything about it was wrong.
The goal of this story is not to give a bad advertisement for a used system, but to share how things should NOT be developed, as well as learn the right approaches when it comes to designing APIs.
Assignment
My friend’s client is using Beds24 system to manage their property listings and keep availability in sync across various booking systems (Booking, AirBnB, etc.). They are building a website and would like the search mechanism to only show properties that are available for the selected dates and number of guests. Sounds like a trivial task, since Beds24 provides an API for integrations with other systems. Unfortunately, the developer has managed to make a lot of mistakes when designing it. Let’s walk through these mistakes, see what exactly went wrong and how it should have been done.
Sin 1: Request body format
Since were are only interested in getting availabilities for properties of the client, only /getAvailabilities call was of interest to us. Even though this is a call to get availabilities, in fact, this is a POST request since the author…
