How we leverage Kong to build a public API
At TheFork, our business is the restaurant world. We ensure that restaurants can receive bookings from a lot of different channels: TheFork portal, TripAdvisor, Google, Instagram, Facebook, TheFork Widget, etc. I can’t even remember them all!
But we also want to make sure that the restaurant can build their own widget or any other creative way of booking through TheFork.
For that we decided that we needed a new developer API.
What was our need?
TheFork provides a reservation widget to be used by restaurants on their own platforms, but some restaurants prefer to have full control on the experience they deliver to their customers.
To build their widget, the restaurant needs to fetch offers and availabilities. And by availabilities, we mean what days from the calendar are available, and for how many people and for which offers and for which time slots, etc.
Analysis started being made between architects, managers and developers on what would we need to provide the best API.
We already have some internal APIs for different consumers, but to keep logic and business separation, we decide to create a new REST API micro-service that will fetch this data and return it to our restaurants.
What is an API Gateway ?
An API Gateway is an entry point for all requests to the APIs. It redirects the flow to the target API and allows to manage aspects such as rate limiting, logging but also security through Authentication, Authorization (OAuth2, ACL), and Accounting. As the number of APIs increased, it became necessary to use a tool to precisely manage access and publication between the APIs and the consumer services/clients. And one of these tools is Kong.
Kong gateway in a nutshell
Kong Gateway is an API Gateway developed by KongHQ (formerly Mashape). It is a single entry point to a multitude of APIs. It is standing between clients applications and your APIs.
HTTP requests will first hit Kong, which will then take care of correctly redirecting the flow to the API provider. The tool is based on a system of plugins that allows to enhance the basic solution with new features.
Why Kong?
In our case, it was already being used to manage our other APIs, so it made sense to use it to manage this one.
It’s really easy to configure, and there are a lot of plugins to reuse, so you don’t have to reinvent the wheel at any time. It’s plug and play.
For this API, we only needed two plugins, one to deal with authentication/authorization and another to add rate limiting to prevent API abuse.
There are several more for other use cases like IP whitelisting, API Key authentication, etc. You can take a look at all the others available here.
Authentication
Security is always a big concern. We can’t let just anyone start using our API and retrieve data that belongs to the restaurant.
We decided to go with Client Credential OAuth flow, where the restaurant is provided with a client_id and client_token provided by our team. Before each request, they must authenticate on our Auth0 server and get an access token, that is sent on the actual request to the API. This token has a short expiration validity, so it can’t be passed around maliciously.
Authorization
Our restaurant is authenticated, but they should still not have access to other restaurants data on our API.
To deal with his, our Auth0 server adds client metadata information on the access token, so that we can validate this data at the API level and make sure that the restaurant is only accessing his own data.
If the restaurant is trying to access data from a different restaurant group or token is expired, it will receive a 401 Unauthorized Error.
How do we configure it
Kong configuration is stored on a YAML file where we can set individual properties for our Kong instance.
At TheFork, we store our Kong config on a Github repository, so that we can version it and create pull requests.
This way, it turns into an easy task to add new consumers, services, plugins, etc.
Developer portal
At the same time we were developing our new API, we wanted to start exposing the documentation for it, so that restaurants could also start developing the integration on their side.
Kong provides a developer portal which allows for developers to get in touch with us and our APIs. We decided to expose our API documentation on this portal.
For the documentation itself, we used OpenAPI 3, which is really intuitive both to write as a developer and to use as a client.
We also version the devportal configuration on a separate repository, similar to what we do with the Kong config.
Advantages of Developer Portal
Besides exposing our API documentation, our Developer Portal provides other useful tools for our internal users that allow for a better developer experience to our partner and help us to manage effectively our API.
- Testing: It includes tools for testing APIs. Our external partners can use these tools to quickly and easily validate their API usage and troubleshoot any issues. This reduces the amount of time and effort required for our IT teams to support external partners.
- Security: It contains tools for our internal teams to secure our APIs and protect our partners’ sensitive data. This includes features such as access control, rate limiting, and SSL encryption.
- Monitoring and analytics: It also provides monitoring and analytics tools that allow us to track API usage and performance. This can help us to identify potential issues before they become major problems and optimize API performance to meet the needs of external partners.
Conclusion
Kong is a great option to manage your publicly exposed APIs. All the plugins and ease of configuration allow for simple managing and not needing to to implement custom solutions for each need.
The initial configuration for exposing this new API was a matter of just around 70 new lines of code on our Kong existing configuration.
In just 6 weeks we were able to expose an API with 5 endpoints with OAuth authentication and authorization, rate limiting and IP restrictions.
If you have a restaurant and want to integrate with our API, or if you are just curious feel free to check our API:
This article was written in collaboration with the awesome Labiedh Kaies.
