How API Connectors Work

What is an Application Programming interface? It's exactly what it says - an interface between two application programs, a piece of software that allows different apps to communicate with each other. In the same way that you use the black box pieces of code on a no-code platform to build an app, your app can use an API to create a connection to another application like Stripe or Facebook and exchange information with that service. The API itself is simply a piece of software installed on the server you want to access. 

When the two computers connect or "integrate" via the API, they have to agree on the set of rules (or "protocol") they're going to use to communicate with each other (similar to two people deciding what language to use to carry on a conversation). Since Hyper-Text Transfer Protocol (HTTP) is the most common protocol on the Internet, many APIs use it as their communication protocol.

Once a connection is established, the client (your app) sends a request to the other computer (the server) and receives one of three responses (an acknowledgment that the request was handled successfully, an error message explaining that the request failed, or the data requested by your app). The request sent by your app is made up of four parts:

• A URL that provides the location you want to connect to on the server. The URL itself consists of three parts:
• The address of the server (www.youtube.com).
• The specific location you want to reach on the server (/results).
• The query string parameters (?search_query=bubble.io).
• The HTTP method:
• GET request - Asks the server to retrieve a resource (a webpage, product, image, etc.).
• PUT request - Asks the server to update a resource (change the address in a customer record for example).
• POST request - Asks the server to create a new resource (e.g. create a new customer record with the data in the body of the request).
• DELETE request - Asks the server to remove a resource (e.g. delete an inactive customer record).
• Header records: Additional information to pass on to the server, such as the time of the request, the request authorization, type of content, and response cookies. 
• The Body: The body of an API request contains the data that your app wants to send to the server and that data has to follow a specific format that the server can understand. A typical API connector encodes the data in a text-based format called JSON (JavaScript Object Notation). Here's an example of data in JSON format:  { “First name”:”Gary”, "Last name":"Morrison", ”Company”:”Global Imports”, "Email": "GaryM@global.com", “Primary contact”:true}.

Most servers require you to send a unique authorization code (referred to as an "API-Key") that identifies you to the server. The third-party service will issue you an API-key (normally a long string of random-looking characters) when you sign up. There are several ways that an HTTP API-key can be included in your request:

• As part of a query string in the URL (?something+API-key). 
• In an HTTP header record.
• A user name and password (which act as the API-key) can be sent as part of each request.

Once the server receives a request it will try to fulfill it, then it will send a response back to the client. Similar to a request, an HTTP response has three parts: a 3-digit status code, headers, and a body. 

Status codes indicate whether the request was handled successfully or not. Common status codes include:

• 200 - Request succeeded.
• 404 - The requested resource doesn't exist.
• 503 - Website is currently unavailable.

There are actually five classes of response:

• 1xx - Request received, continuing to process.
• 2xx - Success (requested data delivered or requested action completed).
• 3xx - Redirection (additional processing needed to complete the request).
• 4xx - Client errors; the request isn't correctly structured or can't be fulfilled.
• 5xx - Server errors; the server failed to handle the request correctly.

Once the response is delivered, that round of the request/response cycle is complete. Any further interaction through the API is up to the client. 

That's the general idea of how an API works - but how do you make use of one on your no-code platform? Most no-code platforms have a way to connect to various APIs, either through some function that's an integral part of the platform, or through a plugin or a third-party integration service. For example, Zoho Creator has an easy-to-follow description of how to use its API service at:https://www.zoho.com/creator/help/api/v2/  

I'll go into a little more detail on the mechanics of API connections in a later post. Meanwhile, I hope you get a chance to experiment with including API calls in your app - API integration has become an important part of application planning, whether for traditional, low-code, or no-code apps.

Use a Simple To-Do List to Evaluate No-Code Platforms

A while back I posted about a simple to-do list built on Bubble and mentioned that it might be worthwhile attempting to add more features to it. In playing around with that app I learned a good bit about how to accomplish different things on Bubble, and it occurred to me that I could use the same approach to learn more about other no-code platforms.

You can build a simple to-do list application in a hurry on any no-code development site. Once that's done you can try adding some of the features Bubble suggests including in their to-do app (obviously not all of these suggestions will apply to every to-do app): 

• Highlight to-dos that aren't completed yet and those that are past their due date.
• Add the ability to edit to-dos - their title, description, due date, etc.
• Add a "completed date" to the to-dos if you don't have one.
• Add a "remarks" field.
• Include a search function so users can search for a specific to-do.
• The original app often shows just the current "to-dos". If so, try adding the ability to display completed to-dos with a create date that lies within a certain date range.
• Let the user set up recurring "to-do" items for regularly scheduled tasks.

There are also a couple of more complicated features that might be worth experimenting with:

• Add "Projects" to the app. Nest to-do tasks inside projects to turn your app into a project manager. That means modifying the existing to-do report or adding a new report to show tasks by project. It may also involve adding new fields like a project due date, project beginning and ending dates, and the person or persons assigned to the project.
• Modify the to-do app so that outsiders can use it too. Add a landing page, a login screen, and permissions so that a user can only see their own entries. All that will

  

  
  require a user table as well, where the user's id and password are stored.

OK, that's about it for my suggestions about an enhanced to-do list. It can be frustrating figuring out how to add features like these without a tutorial to follow, but you'll have a much better understanding of what you can and can't do on a particular development platform.

Get Better Performance from Your Bubble App

Echo Lake Tech has a neat tip on how to speed up user response times for an app created on Bubble.io. The idea involves replacing pages that a user moves between frequently with "group" elements.

Every time you switch to a different page in your app you're accessing Bubble's infrastructure which slows things down slightly. If the user has to switch between certain pages often enough that slight delay can add up, slowing down the user's response time. Creating two or more "virtual pages" on a single page will avoid that interaction and help avoid any slowdown.

Go to https://echolaketech.com/2020/11/02/one-strategy-to-improve-your-bubble-io-no-code-web-apps-performance/ for a full explanation and video of how to implement "group pages". You most likely don't need to do this for all your pages, but it could be worth a look in order to make your app as efficient as possible.