REST API Tester App
  • 01 Aug 2022
  • 8 Minutes to read
  • Dark
  • PDF

REST API Tester App

  • Dark
  • PDF


Before reading this guide, be sure to complete the checklist below by studying the following material:


Sometimes static documentation is simply not enough to showcase the power of your API. Or you may find yourself needing a simple, yet clever API tester for quick queries. With SAP AppGyver, you can build a Dynamic REST API Tester, suitable for both cases. It utilizes Composer's API Integration feature to dynamically get data from the endpoint. App's unique design allows you to change Query parameters and get new results within seconds.

See the application demo below:

Demo GIF

Building the UI

It is generally a good practice to intialize an app build by configuring the User Interface (UI). This way, it is much easier to plan the variables and app logic beforehand.


Header Breakdown

We initialize the header by placing a single Container: Header* view on the canvas. In the 'Layout' properties tab, set the "Layout" to "Vertical" and align components horizontally to the middle. This way, every component added to the container will appear below the previous one and will be aligned to the middle of the screen. Lastly, justfify children components to the middle to prevent elements from appearing lower/higher next to each other.

*Note: 'Header' is a custom name identifier used in the image. Later in the guide you will see similar notation.

Header Layout

To be able to put an icon next to text, we need to drag a new Container: Title into the Container: Header. It is best to use the Layout tree for arranging the components within a Container. In the "Layout" tab of the Container: Title, set the layout to Horizontal to make components appear next to each other. Drag a Title and Icon view components inside the container and set their content to desired values (i.e "REST Countries V2" and the Globe icon).

Title Layout

To finalize the header, drag two additional Text components as 'App Description' and 'API Description' and set their content to desired definitions. For both, it is important to align the text to "center" in the 'Layout' tab, and set the 'Width and Height' to "Fit Content":
Text Config

If done correctly, your header should look similar to the following; You are free to make any customizations, depending on your ideas.

Final Product

Request Entry

One of the core concepts of Composer is component reusability. Since the UI utilizes repetitive containers, we can focus on creating one and later on simply copying it the required amount of times. Below you can find a UI breakdown for a single copy-friendly entry:

UI Breakdown

Below you will find a detailed guide for each element highlighted in Red:


The Container 'Request' holds two elements: 'Request type text' field wrapped in a Container ('Request type border'), and the 'Path' text. Similarly to the Header configuration, set the Layot of the 'Request' Container to be horizontal, and align components to the middle.

We wrap the 'Request type text' into a container, so that we can apply various styles. For instance, set a Positive colored border, representing the 'GET' request.
Request type border

2 & 3

Below the 'Request' Container, we can add a Text field ('Description') and a Button ('Test Button'). The Description contains information about the request, and the Test Button is used to open the Request-Response field.

In order to achive a more compact and responsive button style, we can set the 'Width and Height' to be "Fit content". You may notice that the button will automatically change its size depending on the label. Align the button to the right.
Button Layout


Container 'Testing field' consists of two sub-containers: 'Properties' (4) and 'Response' (5).

Properties Container

Using a Title component, we can title the Testing Field. As before, to be able to put two components next to each other, we add a Container: 'Response' and set its layout to Horizontal. In this case, we put a Text 1 and Input Field 2 view components inside of it. As a styling option, we can again use 'Padding' to adjust the Input Field to an appropriate size:

Padding for the Input Field



Lastly, we configure the Container: 'Response' by placing a Title and a Text component 4 within a Container: 'Response Container' 3 . In this case, using a Container opens various styling options, for instance, a Border.

At this point, the UI configuration is concluded, and will not be changed later.

Adding Data

Next step in app creation is configuring a data endpoint. Since this app is meant for API testing, a REST API data resource is our choice.
REST API Data Resource Choice

Data Resource

Data Resource Home

For every REST API Data Resource, you are required to configure a 'Resource ID', that is going to represent the Data endpoint in the app. In the 'Resource URL', place the base URL of the API. In the REST countries example, it is

Next, navigate to the 'Get Record (GET)' tab to configure the GET request entry for the tester. Add /alpha/{code} to the 'Relative path' in order to finish the request URL. Since our tester is dynamic, it is necessary to be able to change the request URL with the UI. To achieve that, we can use a 'URL placeholder'. Simply create one with the 'Label' and 'Key' set to "code" in order for {code} in the URL to be bound to its value.

Get Record

It is important to uncheck the 'Is static' and 'Is optional' properties of the URL placeholder, to make it mandatory for the API request.

Making the URL placeholder mandatory

Finally, we need to test the API connection via the 'Test' tab. Enter any valid value (i.e "FI") for the URL placeholder and click "Run Test". If the request was successful, you should see 'Status: OK' in the top right corner, and 'Set Schema From Response' button should become available. Press that to finalize the Data Resource configuration.

Testing the API

Data Variable

Upon making the Data Resource, you are should continue by creating a Data Variable that is going to hold the value of the Response. Navigate to the 'Variables' view, then choose 'Data Variables'. Click on 'Add Data Variable' and choose your Data Resource from the drop-down. In the image below, the 'Rest Countries' resourceID has been changed to 'SearchViaCode', as it is a good practice to have name every data resource according to its purpose.

Creating a data variable

On the right, in the 'Properties' tab, configure a name for your data (in our case, countryRecordViaCode). Set the 'Data variable type' to 'Single data recourd', since our API is using 'Get Record (GET)'.

Data Variable Properties

You may notice a 'Required property' titled "Country code". This is the URL placeholder configured before. In order to be able to dynamically edit the code from the UI side, we need to bind it to a Page Variable. Navigate to the 'Page Variables' tab on the left and create a page variable titled "countryCode" with a 'Variable value type' to be "Text". Return to the 'Data Variables' view and bind the created page variable via 'Data and Variables -> Page Variable -> countryCode'.

Page Variable as URL query

Page Variable

Variable configuration is finalized by creating a "True/Flase" Page Variable that is responsible for showing and hiding the Request-Response field in the UI.

Visibility Page Variable

Connecting data to UI

After configuring all required assets, we are now able to connect them to the UI.

To enable the dynamic changing of the URL Placeholder, bind the created Page Variable (countryCode) to the 'Value' property of the Property Input. Since Page Variables natively support two-way binding, the value of the countryCode will be immediately changed upon any user input.

Property Input Two Way Binding

Next, we want Response Text to display the data from the API. Thus, we need to bind its value to the Data Variable created earlier. At this point, you can bind it directly to the data variable and have the data displayed in the raw format. However, to achive a clearer output, we can use formula binding and style the output in any way we desire. Below you can find a formula function used in the app demo to create a clean and dynamic output:

"Name: " + + "\nCapital: " + + "\nRegion: " + data.countryRecordViaCode.region + "\nSubregion: " + data.countryRecordViaCode.subregion + "\nPopulation: " + data.countryRecordViaCode.population + "\nTimezone: " + data.countryRecordViaCode.timezones[0] 

By using the mathematical sum expression (+), we are able to append data from the data variable to a static string. "\n" indicates to begin the next entry starting from a new line.

Configuring Logic

To able to hide and show the 'Testing Field', we need to configure logic that will do so on Button click.

First, bind the 'Visible' property of the 'Testing field' to the true/false Page Variable created previously. This way, the visibility of the component will depend on the value of the Page Variable. For instance, setting testingFieldVisibility1 to false will hide the component and only display the Button and the Description.

Binding Component Visibility

To be able to control visibility with the 'Test Button', we can use the 'Set page variable' flow function attached to the 'Component tap' event. This way, the change will occur every time the button is pressed.

Button Logic

To 'reverse' a value of the testingFieldVisibility1 we can use the following formula as binding for the 'Assigned value':

IF(IS_EQUAL(pageVars.testingFieldVisibility1, false), true, false)

By using the 'IF' statement, we verify whether or not the Page Variable testingFieldVisibility1 is equal to false. In case it is, we set it to 'true'. Otherwise, it is set to 'false'. This way we reverse the value of the variable every time the check is executed.


Open the app in Preview and test the logic configured a moment ago.

Testing without a value

In the 'Testing field', upon entering a country code, you should see the 'Response' field change.

Testing with a value

It may take a several seconds for the response to appear. To make it happen faster, we need to reduce the API call delay. To do so, navigate to the 'Data Variables' view and open the Logic canvas. Select the 'Delay' utility flow function and change 'Time to wait' to a desired value.

Increasing the API call frequency


Making a lot of requests to a public API may result in rate limiting and affect the app's capabilities. It is adviced to not decrease the delay below 1 second.

Extension: Design suggestions

As was stated before, the 'Entry' UI component is highly reusable. Upon copying it, you can much faster add new entries without having to create them from scratch. Below you will find some inspirational entries for Entry design.

DEL and POST request styling

Was this article helpful?