Introduction
Softr, a No Code tool that is widely used by businesses to build custom apps, client portals and Internal tools has recently introduced REST API integration as one of it’s options. It already has built-in options to connect to other back end tools like AirTable, SmartSuite, Google Sheets, Xano, Supabase, traditional databases like MySQL, PostgreSQL, MariaDB to name a few. Recently they introduced Notion Database as another data source option.
Guess what’s the most latest in their data source suite? Yep, as the title reads, it’s none other than the REST APIs.
So what exactly is a REST API? Let’s break it down into API and REST.
API: Application Programming Interface aka API is nothing but a set of protocols for building and more importantly integrating different components of an application. In other words, it’s more like a contract between the component that provides information and the component that receives information.
To give a simple example, let’s assume there is an area in my client portal that displays a welcome message along with that day’s weather details as soon as a user signs in. Probably, what’s the temperature in their location, whether it’s going to be sunny or cloudy or rainy and so on. Just some basic weather details 🌞☔❄
In such a case, it’s smarter to use an API like WeatherAPI. All it requires is for the caller to send few mandatory as well as a bunch of optional parameters as part of the request. In most cases, the API_KEY is required as a mandate. This lets the API server know who is making the request. On top of this, parameters like the city where the user lives, zip code should be good enough to fetch the daily weather.
Using an API is a brilliant way to connect multiple tools and resources in a secured manner, thus saving a lot of development time. If you are interested to learn more about the basics of an API, here is a good resource from Red hat.
REST: REST stands for representation transfer and is nothing but a set of architectural constraints and it can be implemented in a variety of ways. All it’ll need is to adhere to set of constraints to be called RESTful.
In order for a user to send a request to a REST API, it’s usually sent using Hyper text Transfer protocol aka HTTP. Response from a REST API can be sent in different forms, JSON being the most common one as it can be read by any programming language as well as human readable, it is very lightweight too. Other common response formats are: HTML, XML and plain text.
Quoting from Red hat regarding the 6 architectural guidelines, here they are 👇
A client-server architecture composed of clients, servers, and resources.
Stateless client-server communication, meaning no client content is stored on the server between requests. Information about the session’s state is instead held with the client.
Cacheable data to eliminate the need for some client-server interactions.
A uniform interface between components so that information is transferred in a standardized form instead of specific to an application’s needs. This is described by Roy Fielding, the originator of REST, as “the central feature that distinguishes the REST architectural style from other network-based styles.”
A layered system constraint, where client-server interactions can be mediated by hierarchical layers.
Code on demand, allowing servers to extend the functionality of a client by transferring executable code (though also reducing visibility, making this an optional guideline).
In the context of this article, we are not going to write an API, we are only going to use APIs. Hence, I plan to focus on API definitions, their constraints, how they need to be invoked, especially from Softr.
Nevertheless, if you are interested to spend some more time to go a bit deeper into what REST is, what are the architectural guidelines, please do check this detailed article from IBM.
What do we plan to build?
Alright, now that we know what a REST API is, let’s look at what we’ll be tackling here.
Let’s build a Softr app that integrates with Spoonacular aka the Food API. We shall make use of the newly introduced REST API integration to perform the same.
So, what does this app do?
To start with, we fetch recipes based on the cuisine of our choice. As a next step, we go deeper to understand more about the recipe in terms of what ingredients it needs, what is the cooking time, preparation time, a summary of how to cook, along with the source URL.
How do we do this?
We invoke 2 APIs, one to search recipes and another to fetch recipe information. We show the results in a List page and List details page.
To keep things simple, I’m not planning to bring in authentication as part of the app. It’s just going to be 2 simple pages.
Common, let’s go 🍕🥘🥧🍪
Spoonacular at a glance
Recently I wrote another article on integrating Spoonacular with toddle, another No Code front end tool. Just to save some time here, I thought there’s no harm in picking up some content from my previous article 😁
Spoonacular is a massive database of food related information. If you are building a app for meal planning, or recipe management, or recipe analysis or anything related to food, meals, groceries, then your go to place is Spoonacular. They have a generous free plan for you to play around and familiarize with the APIs.
Below are the steps to be followed to get started:
Sign up or Login with Spoonacular, depending on whether you do not have/have an account.
Once you sign up/login, you will be taken to your dashboard. Click on Generate New API Key. Click on Show/Hide key when you need to copy it and use it in toddle while invoking the API.
Let’s take the first API, Search Recipes. It has a lot, a lot of parameters that can be used. You can read through the page to see the inputs it can take and what comes back as response. Let’s probably choose a few inputs like cuisine, diet, to pass in our Softr app.
Here’s a sample Request/Response for the above API
The other API that is of interest to us is the Get Recipe Information. This API just needs the recipe ID as a mandatory URL parameter and it fetches a lot of information with respect to the recipe being fetched. There are a handful of other input parameters that can be passed too.
Here’s a sample request of this API and the partial response.
If you want to play around with these APIs, use a tool like Postman and try with
different input parameters, provide different values to see how the response changes. Their documentation is pretty exhaustive. Do check their complete list, it’s very interesting!
Configuring the Spoonacular APIs in Softr
Okay, next step is to start defining the API as a Data source in Softr.
💡
REST API feature is available for Business users and higher.
Shall we get started? Follow the steps below to start defining your resources now.
Sign in to Softr
In the left pane, you'll find three options at the top: Apps, My Templates, and Data Sources. Click on Data Sources.
When you land on the Data Sources page, you should see a Connect Data Source button on your right.
Voila, here’s what you should see, yes, as the last option in the list you should see Rest API.
Click on Rest API BETA and then click Continue
As of today, Softr provides 3 ready made templates (Stripe, Intercom and Shopify) and also an Add Manually option. Let me reserve the template for a future post 😀. Since we plan to use Spoonacular, we click on Add Manually and then on Continue.
Here’s how the screen looks like:
Let’s give it a Name “Spoonacular - The Food API”
We add two parameters under Header, the Content type and the API Key. This is how it looks like 👇
💡
Note that I just gave it as xxxxxx against x-api-key for the purpose of this blog. Scroll up to the previous section to find out your Spoonacular API Key. Copy/Paste it from your Spoonacular dashboard.
On adding these parameters, click on Continue. You will be taken to a page where there is just one button that reads + Add Resource. Here, Resource refers to the actual API definition. Let’s define 2 resources, one for Search Recipes and the other for Get Recipe Information.
In the next page, we set up the API. I gave it a name Search Recipes and gave the URL as https://api.spoonacular.com/recipes/complexSearch
The HTTP method is GET as it is a GET request.
Below this section, you see 5 tabs to be active; Headers, URL Params, Placeholders, Pagination and Transformer.
Since we gave the header details at the Data Source level, we need not give them again. If we have any attributes specific to this API, we can add them. In Search Recipes case, there’s nothing to be added.
Click on URL Params. We can add as many parameters as we want, the upper limit is dependent on what the API allows. In Search Recipes case, there is a lot as I mentioned earlier. Let’s choose cuisine, diet, and number.
Here is what each of these parameters mean (from Spoonacular docs):
cuisine - The cuisine(s) of the recipes. One or more, comma separated (will be interpreted as 'OR'). See a full list of supported cuisines.
diet - The diet(s) for which the recipes must be suitable. You can specify multiple with comma meaning AND connection. You can specify multiple diets separated with a pipe | meaning OR connection. See a full list of supported diets.
number - The number of expected results (between 1 and 100).
These are the values I gave:
Next tab is for placeholders. Placeholders are usually values that need to be replaced in the URL or they can be query parameters, in which case we mention as key-value pairs. In Search Recipes we do not need any placeholders, so let’s just leave it empty.
We still have Pagination and Transformer tabs to explore. Before we do that, let’s go ahead and execute and see what happens. Then you’ll be able to appreciate the Transformer and Pagination tabs better 😊. Alright, go ahead and click on Execute button placed above these tabs.
Now scroll down a bit and you should see 3 more tabs, Schema, Transformed JSON and Raw JSON. This is how the Schema tab looks like 👇. It’s nothing but the response structure. In this case, the response contains an Array named results, a number named offset, and so on. This is what Spoonacular returns.
offset - The number of results to skip (between 0 and 900).
A preview of Raw JSON
It has 10 such results as we specified the number as 10. This API returns an id, a title, an image and image type (jpg or png etc.,) within the results array. Other than this, it returns an offset, a number and totalResults. totalResults denotes the total number of recipes this API is capable of fetching from it’s database.
Next click on Transformed JSON. It pretty much looks the same as Raw JSON. Infact, it is exactly the same because we did not write any transformer yet.
Let’s now move on to writing a Transformer. Why do we need a transformer in first place? Most of the time, the Raw JSON that is returned as a response may not be required as is, especially in case of public APIs. We may only need a subset of the response variables, sometimes we may need to apply filters, for example, we may want to convert the title of our recipe to upper case, we may want to display a cost variable with just 2 decimal places, with a date variable, we may want to show it in a different format and so on. All such modifications is possible through transformer.
Let’s write a super simple transformer that fetches each object from the array, and just the title and image.
return response.results.map(recipe=> {
return {
id: recipe.id,
title: recipe.title,
image: recipe.image || "N/A"
};
})
Why are we fetching as an object and not keeping it as an Array? That’s because we need a handle to the individual ids directly so that we can use it to pass as an input to our next API, the Get Recipe Information. Now click on Execute, you should see a difference in Schema and in Transformed JSON tab.
See the difference between what we saw in our previous screen of Transformed JSON? Do pay attention to the id field that has a check mark against Is ID field. We will need to mark atleast one field as an id to get a unique handle. In this case, the name of the field is also id.
Time to move on to the next API, the Get Recipe Information
Like how we added a resource for Search Recipes, click on Add Resource button.
In this case, we do not provide any values under Header, URL, Placeholders, and Pagination, because this API returns just 1 recipe
The only tab that is of interest is the Transformer tab. The original response has way too many parameters. It would be impossible to make use of every field in the UI. Instead, I picked and chose a few fields that I felt might be interesting to show.
In order to do that, we write a small piece of javascript code. It’s quite similar to last time, just that we have a mix of single value fields as well as an array. Pay attention to the code 👇
extendedIngredients, a response variable is an Array and each object in it has a lot of fields. I just selected name from this. The rest are single valued fields.
const ingredientNames = response.extendedIngredients.map(ingredient => ingredient.name);
return {
id: response.id,
title: response.title,
image: response.image || "N/A",
cookingMinutes: response.cookingMinutes,
preparationMinutes: response.preparationMinutes,
healthScore: response. healthScore,
sourceUrl: response.sourceUrl,
dishTypes: response.dishTypes,
dairyFree: response.dairyFree,
vegan: response.vegan,
summary: response.summary,
ingredientNames
};
Now click on Execute, check whether the Transformed JSON tab has the fields that we defined above. Look at Raw JSON tab to see the massive amount of information returned.
Now click on Save
Yaay, we are done configuring the APIs that we need ✨. Let’s move on to the User Interface part.
Time to build a Softr app ⌚
Let’s build a simple app with just 2 pages, more to display the data that the API returns. One to display the search results and the other to display the detailed recipe information. This shouldn’t take a lot of time, let’s zoom in 👓
Below are the steps to build our app in Softr:
Navigate to the Home page and click on Start from scratch block that shows on the top
In the next page, you need to choose your Data Source. Ideally, it should be a backend like Xano or Airtable or the other choices shown, as most of an applications’s data resides in some sort of a database or a backend. REST API can provide data for a few cases, not all.
In our case though, I choose REST API as my backend as I intend to build just 2 pages.
Once I do that, it opens up an untitled application. I clicked on Pages, and this is what it looks like 👇
We can either delete all pages and add two new pages. Or we can re-name and start to use from the above ones. I’ll choose the latter 😀.
Since there is a List page and List details page, let’s rename them to Recipes and Recipe Details. Also, let’s name the application as Recipe Explorer.
To change a Page name, click on the Settings icon beside it and choose General.
Do the same for the List details page. Name it as recipe-details and /recipe-details under Page URL
Alright, let’s now configure the data source for the list page. As you may expect, we choose the Spoonacular, the Rest API that we just created
In the next tab, which is the Content tab, I map just two fields as we just fetched the title and image that can be used. I hide the rest or delete them as appropriate.
I hide the Search bar and deleted the two inline filters that come by default.
Click on Publish on top right corner. You can leave the default name it provides or change it. I changed it to recipe-explorer.
- Cool 😎, let’s choose the recipe-details page from the Pages list and start configuring. As always, as a first step configure the Source. We choose Spoonacular REST API and Get Recipe Information as our source.
In the Content tab, choose the appropriate datatype to the response field. This is how my sections now look like 👇
And Section 1 looks like this 👇
I deleted the remaining sections. As a final step, I modified the action and label of the button present on the recipe-details page. By default, it comes as Edit. I just made it a Back button like so 👇
We are all set, click on Publish and click on Preview from recipes page. It should be loaded with Spanish recipes 🤭. Click on any recipe and it will take you to the detailed page with more information. Cool, isn’t it?
Here’s my published app. Play around!
In future posts, let’s see how to write more complex transformers and how to paginate the results. We shall also use Softr’s pre-built templates for REST API, Shopify, Stripe or Intercom and see how they can used. Or, let’s write our own API and use that too. Sky is the limit!
In this post, we saw a brief about what a REST API is, a brief on Spoonacular’s API, how to connect to Spoonacular API using Softr’s REST API option and add resources, building a 2 page app and making use of the the API’s response to display results, give action to each of the response item.
Hope you enjoyed the post and found it insightful! If you have any questions, thoughts, or ideas, feel free to share them in the comments. Happy building!
