API Fortress is a continuous testing platform for APIs. We’ve been a friend to Kong since the beginning. In this guest blog post, we explain how our company uses Kong to facilitate the process of virtualizing APIs.
Why Mock APIs?
As more companies adopt microservice architectures and DevOps best practices, APIs play a bigger and bigger role in software development. The explosion of services and APIs makes control platforms like Kong imperative in the new API economy. Many companies want to innovate faster, and the push towards shorter and more effective sprints has made Continuous Integration and Continuous Delivery (CI/CD) a popular practice. This practice requires automated testing, but even companies that haven’t implemented instantaneous deployment patterns can still accelerate development by automating API tests.
API Fortress builds tools to automate API testing. Our experience working with customers and their API testing challenges has highlighted a prevalent requirement – mocking APIs. Companies we work with need to mock APIs for three common reasons:
- To build tests early: Teams need to mock APIs so that they can start building tests for those APIs before the APIs are live.
- To save money: Paid APIs like Google Maps and Salesforce can be expensive to make calls to. Mocking APIs allows teams to save money on these calls during development.
- To detect bugs: Mocking APIs during bug hunting allows teams to hone in and diagnose which specific microservices might be causing a hard-to-solve bug.
There are many more reasons, but those are three of the most common.
Architecting an API Mocking Solution with Kong
The idea of mocking an API might seem simple, but in practice, the existing options that users had for mocking were limited. Open source libraries take a lot of effort to set up, and existing paid platforms can be overly expensive and sometimes limited. At API Fortress, we believed that a simple, robust option was needed. So we built one.
The experience of creating mocked APIs in our platform is fairly straightforward: users simply copy and paste the payloads into our GUI. But, we wanted to find an even easier route. We wanted our platform to automatically create mocks from live API calls. The goal was to find a method more powerful than recording manual calls that users make from their desktops. We’re a platform, after all, so we wanted to take a platform-level approach.
While we were architecting our solution, we realized that Kong could be a critical component to intercept real API calls and responses, which we could then use to generate mocks.
With our plugin, Kong can capture snapshots of payloads that pass through it and send those snapshots to API Fortress. Our platform can then automatically turn those calls into mocked APIs with the click of a button. One click, and an entire organization has access to virtualized API. Cool, right?
How Does API Mocking Work?
Users can set up API mocking in a few steps, which are described in the API Fortress documentation here.
The basic process is broken into three steps:
- First, we’re going to turn on the Kong proxy server.
- Next, we’re going to create a proxied endpoint.
- Finally, we’re going to push that proxied endpoint into API Fortress mocking.
Our mocking feature is only available for the on-premises version, but we offer a free 30-day trial. If you’d like to follow along, simply sign up for an account, and our team will help you get a container (Docker/Kubernetes/Open Shift) to deploy. We’ll summarize the general steps to use mocking below, which may help you think about your own implementation.
A trial provides you with a few prerequisites for mocking with API Fortress, including:
- An updated version of the API Fortress
core/docker-compose.yml(if using Docker, for example), which includes the Kong section at the end
- The initialization script,
- The start script,
The first step is to start Kong and its prerequisites, which include a database. You can use Cassandra or Postgres with Kong, but in our example, we use Postgres, which we provide a preconfigured instance of as part of the API Fortress container.
Next, we need to initialize Kong using the previously mentioned script, init_kong.sh. Once Kong has finished initializing, we can start the Kong container itself. We do this using our provided docker-compose file. After the file runs, you want to check and make sure that the container is running.
We can verify that the proxy is up and running using a cURL command or the HTTP client of your choice. A positive response from this route indicates that the proxy server is up and running. Congratulations! You now have a live proxy server!
Our last step in the setup phase is creating an API Fortress API key. The gif below shows the process.
Proxying a Route:
Every time we create a mock route, we need to point it at the dashboard. The simplest way to do so is to add a wildcard entry to our DNS. If that is not an option, individual DNS entries for each mock route are also an option. If API Fortress is running at
apif.example.com, the wildcard entry of
*.apif.example.com would point at the same IP address and allow every prepended domain to reach the same server.
In order to proxy an API route, we need to POST a request to the proxy server that contains the following information about the route in the header:
name: The name of the API profile
upstream_url: The origin URL, which is the destination that we’re passing through the proxy on our way to
hosts: A list of hosts that will trigger this API profile, which is formatted as the URL(s) that will trigger the proxied response
The result is a profile of a proxied API.
Finally, we need to test the proxied route itself. To do so, curl the URL that you previously defined as the host appended with port 8000, accompanied by any key-value pairs you need to submit and necessary routing information. Our expected response should match the response of the endpoint that we’re proxying, provided we’re passing the correct headers.
Recording a Mock Endpoint:
As with creating the actual proxied endpoints, creating recorded mocks requires a modification of the DNS. Adding a wildcard entry for the mock server (
*.demoapi-mocks.apif.example.com) will allow these requests to be properly routed once the mocks are recorded.
Activate Mock Recording:
The next step is to activate the fortress-http-log plugin for Kong by sending a POST request to
apif.example.com is the URL of your API Fortress instance.
The request should pass a number of URL-encoded key-value pairs in the body, which are commonly known as post parameters. These values are largely static.
config.api_key: The API Key value created in step 1
config.secret: The API Secret value created in step 1
config.mock_domain: The mock domain you wish these routes to be appended to in API Fortress Mocking; it does not need to already exist
Once the request has successfully been sent, the fortress-http-log plugin for Kong will be active, and mock recording will be enabled!
Record an Endpoint:
You can then start recording mocks by calling the proxied API. As always, note that the proxy route in this call must be replaced with the proxy route that you created. The port, in this case, is 8000 (Kong’s proxy port) rather than 8001 (Kong’s admin API port).
Query the Recorded Mock API:
Finally, we can verify the new mock route in two primary ways. First, we should see it in the Mocking interface in API Fortress. Second, we can query the route directly and receive the same expected response to this call that we receive when polling either the actual or the proxied API.
Learn More About API Fortress and Kong
As you can see, Kong plays a central part in our Mock API recording. We’re proud to be part of the Kong community and are excited to see the project growing. 1.0 added some particularly interesting features, and we look forward to doing more together in the future.
For the full documentation on mocking with API Fortress and Kong, or to learn more about what we do, please visit us online. See you around the Kong community!
Subscribe to Our Newsletter!
Connect with Kong users and keep up with Kong news