Validating an external API with Composable Web Requests

At my previous job, I was reliant on external API’s to work correctly and to know when functionality had changed. With proper acceptance/validation testing on foreign API’s, you can sleep a little bit better at night knowing that the behavior hasn’t changed and is still returning competent results you can rely on. Lets walk through how to set up validation testing with DataFlows.

[I’m going to use the public API provided by coindesk.com for historical bitcoin price data. If you want to try this out too, feel free to use the same endpoint as it doesn’t require any external authorization/token to use.]

1. Hop into the Composable DataFlow designer and start out with the WebClient module. Change the module Method to GET, use the Uri https://api.coindesk.com/v1/bpi/historical/close.json?start=2013-09-01&end=2013-09-05, then click run and check out the results. Since historical data shouldn’t change, our results should look the same.

2. For this particular example, we can do a direct comparison from the response we get in our web client now to a response at some point in the future. What we will need now is a “string input” module and a “python code” module. Additionally, copy the result of your WebClient response (using the copy icon at the top left of the floating results window) into the string input module so that we now have a response to validate against. (If you happen to have response fields that change depending on when or where you call the endpoint from, you will want to parse your string response into a JSON object first so that you can compare the individual fields instead.)

After you hook up your inputs (shown below), lets write a function named “responses_are_equal” to check the equality of the responses, then run the modules by clicking on run. Hopefully your response from the python code module came back as true because these two response strings should be identical. Make sure to check your responses from each individually, and if you are still having trouble you can use the template DataFlow provided in a link at the end of this post.

3. The two last modules to add are our Web Receive and Web Send modules. You don’t need to hook up any inputs or outputs with your Web Receive module, just make sure to set the method to GET. For your Web Send module, just leave everything as the default and hook up your Python Code module output to the input of the ResponseIn field. Also, to make our responses a bit more dynamic, you can update your python function code to be a bit more precise with the following…

And that’s it! Lets validate to make sure everything is put together correctly.

Make sure to save your DataFlow and take note of the DataFlow Id, which can be found on the right-hand side of the page (also can be found at the end of the URL in your browser’s address bar). Next, go to your profile page and click on the “generate api token” in the top right of your page. If you are not familiar with api tokens, they are essentially your credentials for your user account (never share your keys!).

Now open up your tool of choice for making web requests (I will be using the curl command in bash, but you could use something like Postman to log your endpoints and test results).

Looks like we got back the response we were hoping for! Lets just do our due diligence and make sure that it’s working correctly by messing with the Validation string a little bit…

This is exactly what we hoped we would get as a response this time, invalid validation string should return a failing test. (As a side note, for the purpose of this tutorial I first got a passing result before making sure it fails when it should. Typically, I would write a test that fails before I try to get a passing test, as that’s a much more natural way to validate your output.)

To bring this to an end, I wrote about this particular topic because I thought it was a neat idea to be able to easily validate with acceptance testing using Composable DataFlow’s. Using this in conjunction with something like Postman could give you a 1-1 relationship of endpoints that your development and testing framework uses. Instead of needing acceptance testing code inside your testing library, I think it’s a bit more natural to have a companion (endpoint/validation-endpoint) pattern to keep them at the same level of scope.

I exported the DataFlow (I’m going to leave the validation string as-is so that your test will fail first before it passes) to a JSON so that you can re-use this module and test with it if you like. You can use the import at the top of the designer page. (you’ll have to convert it from a .txt to a .json because JSON isn’t an allowed file type for blogs evidently).

Have a great weekend,
Mike

• Author
• Recent Posts

Andy Vidan

Andy has diverse and extensive experience spanning data sciences, information technology and applied physics, with a passion for developing and scaling disruptive technology platforms. At MIT Lincoln Laboratory, Andy served as a key technical contributor to a broad range of homeland security and defense research programs, and was the architect for the Laboratory’s Distributed Disaster Response program, developing advanced information systems for large-scale crisis response and management. Andy has a PhD from Harvard University and a BS from Cornell University.

Latest posts by Andy Vidan (see all)

• Validating an external API with Composable Web Requests - June 26, 2021
• Moving Forward with DataOps - February 21, 2017
• Analytics Readiness with Composable - February 9, 2017