Project Description & Goal

Application Programming Interfaces, or APIs, are widely used in software development. Knowing how an API behaves is important whether you're a developer building one or a user incorporating it into an application. It becomes difficult to provide the consumers with the necessary information when interactive software is lacking to investigate an API's behavior. The goal of the APIExplore project is to build demonstrator software that allows developers to easily interact and understand the behavior of APIs.


The result of the project is a web-based single page application (SPA) that contains the implementation of all the specified features. The major functionalities of the tool are listed briefly: 

  • Importing API Schema three ways: Fetching from a URL, uploading a JSON file, and fetching previously uploaded schema from a database. 
  • Constructing API call sequences: Users can add call sequences by filtering using HTTP method, arrange their call order. They can also upload call sequences as a file. 
  • Timeline View: Users can view the timing of the API calls in an interactive timeline visualizer window. 
  • Dependency/Relationship Visualization Graph: The connection between different API calls is displayed in a dependency graph interface. 
  • Control the state of the System Under Test (SUT): Users can start, stop and restart the SUT. 
  • Performance Metrics Analysis: The performance metrics of the API calls are provided for the user. 
  • Logging and Sequence configuration: Important logs are provided in a logging window and API call sequences can be configured to be performed in a call-by-call manner. 
API selection menu
API schema selection menu
Existing schema selection menu


Timeline view


Dependency graph view


Relationships view


Call sequence configuration menu
Previous sequences menu


Architecture overview

Based on the specifications, a high-level system architecture is created as shown in the following figure. The architecture of the system consists of three components. The visualizer, API explorer, and SUT controller are meant to operate independently and communicate with one another. The application starts from the visualizer interface, where users can import or generate API call sequences and initiate the exploration process. Additionally, the visualizer offers ways to interact with the SUT controller, manage the status of the SUT API, and send commands to it.


High-level System Architecture


The client's needs are the main factor that led to this architecture's selection. He says it's critical to maintain the system's modularity. After more conversation with the customer, the team decided against implementing the agent with the visualization back end in one component, as he indicated his intention to maybe run it on a different machine (containing the SUT). It had to be kept apart from the rest of the system as a result. The ability of the team members to split the available work while reducing wait times, or "bottlenecks," between jobs was another advantage of keeping the various components of the system distinct.

Sequence diagram of basic request flow between system components


The previous figure shows the typical request flow when performing exploration from a fresh start of the application. First the visualizer requests a list of available APIs (SUTs) from the agent component. The user then selects an API which sends a start request to the agent. The agent launches the API and waits until it has started completely before sending back a confirmation along with the PID for the API process. Once a confirmation is received, the user creates a new schema which is then uploaded to Firebase. The explorer parses and returns the operation defined in the schema back to the visualizer. The user then uses the UI to construct a call sequence and initiates the exploration request. The explorer builds the API calls and sends them to the SUT, awaiting responses, and recording the response data. The response data is then sent back to the visualizer to be displayed, while the explorer continues and uploads the call data to Firebase. Once the user has finished exploring the call data, they send a request to the agent to stop the API. 


For the frontend development (visualizer) the following technologies were used: 


  • React is a foundational library for building user interface. 
  • Its component-based architecture provides modularity, making it easier to manage complex UI structures. 
  • Reacts virtual DOM ensures efficient rendering, enhancing the overall performance of the visualizer. 


  • Vite is utilized as the build tool for the React application. 
  • Its speed and efficiency contribute to a rapid development process, allowing quick iteration and refinement of the user interface. 

For the backend development (API explorer and agent) the following technologies were used:

Node.js + Express:

  • Allowed us to define clear and separate routers for managing the different responsibilities of the backend, such as management of API schemas, call sequences, exploration requests, and SUT state.


  • Providing an easy to use API for reading and writing API schemas and call data.

Project links

Links to project's GitHub repositories:

Link to project's Figma design mockups: APIExplore Figma Design


Bahareh Aghajanpour (Scrum master, Backend Engineer) - bar22002@student.mdu.se

Henok Birru (Backend Engineer) - hbu23001@student.mdu.se

Johannes Finn (Product Owner, Backend Engineer) - jfn18004@student.mdu.se

Gabriel Kazai (Backend Engineer, Secretary) - gabkaz25@gmail.com

Marko Uremović (Frontend Engineer, Git Master) - marko.uremovic@fer.hr

Neda Kušurin (Frontend Engineer) - neda.kusurin@fer.hr

Felix Bečeić (Frontend Engineer, Git Master, Designer) -  felix.beceic@fer.hr

Edin Ibranović (Frontend Engineer, Designer) - edin.ibranovic@gmail.com


Robbert Jongeling (MDU) - robbert.jongeling@mdu.se

Igor Čavrak (FER) - igor.cavrak@fer.hr


Stefan Karlsson (ABB Sweden) - stefan.l.karlsson@se.abb.com