APIs. We all encounter them almost on a daily basis, either by designing, developing or consuming them. So most of us will have encountered at one point or another an API that does not behave as advertised, often leading to frustration. But how do we ensure delivery of a quality API? That’s where API testing comes into the picture.

Before we go further, let’s set some expectations here. I’m not a dedicated tester; I’m an integration analyst/architect that was asked to perform testing on APIs. As I have been spoiled in the past by having dedicated testers available, I had never put too much thought into it, to be honest. So I went searching for an approach that could work based on my current and past work experiences.

Recently we did some research into the intricacies of communications in a microservice architecture, and we want to share our insights with you!

For those who cannot wait for our findings, we are strong believers that asynchronous communication is the way to go. The use of synchronous communication should be limited to only specific use cases. If you want to know how we reached this conclusion you will have to read through the entire blog. But be aware that getting this aspect right in your architecture is crucial as a microservice architecture heavily relies on communication between its components (microservices).

On September 23rd, our API expert Edwin Hurst (Archers) and Integration Lead Jolien Jans (Fednot), were guest speakers at the 14th lunch session of the API community. Since we’re very proud of our team member and partner, a short recap of the session is written below!