Web API Component Example (with videos)

Tutorials and DIY Guides
,
1

Background

One component I’ve been interested in lately is the Web API. The Web API enables your app to retrieve data from a service on the web like weather patterns or currency exchange rates over the past 20 years.

In my example, I use the https://www.openbrewerydb.org/ API to search for microbreweries by city and state. You can find this API and many others here: https://github.com/toddmotto/public-apis.

Tutorial 1

My first tutorial covers the basics of calling, reading, and display data from a web API.

Tutorial 2

My second tutorial dives one level deeper to show how to dynamically populate an API call URL to query the API based on the user’s request.

Docs

https://docs.thunkable.com/web-api

In Closing

I hope this helps you, and I’d love to see examples of how you are using the Web API component in your app. :face_with_monocle: :relieved:

Happy Coding!

Darren
Thunkable X Tutorials

4 Likes
2

I had a (Thunkable) program I was trying to get listed on the Apple App Store. One of Apple’s objections related to a hidden URL call that they felt might change in the future and make the app not perform properly. Have there been any significant issues getting apps that utilize the webAPI capability approved for the Apple App Store? I needed to get the app on the store ASAP and ended up paying a developer to write an app in Swift in order to get it approved. I don’t understand the difference, hence my inquiry. I’m currently working on a newer version of the app in Thunkable and would like to know I’m not wasting my time.

3

Just a quick question.

Would Apple have objected if your app had a field where someone could enter an alternate URL to be used in replacement for the one already coded?

4

Interesting concept. I don’t know. If I get push back when I resubmit my app for approval, I may offer that as an alternative. However, I have to believe there are many apps that have “hidden” API calls and they’re approved.

5

I am sure there are, but that is not really the issue here. Pointing out that there are is more likely going to trigger them into searching for and rejecting those apps retrospectively than establishing a tolerance going forward…

The point is that Apple is playing a bit the dictator and wants to decide everything. Their rules are
1- Apple is right
2- If you prove that Apple is wrong, Apple reserves the right to change the conditions so that #1 is true.

20 years ago, at a workshop for Six Sigma Black Belt on creative thinking (Flexible Thinker), during an exercise, Michael Rosenberg had just decided to throw me a curve ball and changed the rules. When I protested, he said “in the real life, do you want to waste all the time in court proving you are right, or shouldn’t you just adapt in order to not lose the market?”

1 Like
6

I appreciate your perspective and feedback. Thanks. I’ll just have to wait and see what happens when I resubmit my updated app!

7

Let us know how it turns out.
My unit calculator app, which is presently on Classic Thunkable and therefore only available for Android machines, is relying on a very specific web site to get the current exchange rate between currencies, and has to parse the HTML to extract those values; and an eventual port to X (when the required canvas and web_string are added) to support iOS would be futile effort if Apple claims that “themoneyconverter.com” might change its URL.
So, this is not completely disinterested on my part.

Good luck.

1 Like