APIs revisited and wonders of the web

There have been several posts about Application Programming Interfaces (APIs), but little explanation or motivation.

Everyone knows that the world wide web is bursting with useful and interesting information. Generally we get this information in our browser. 

Besides the countless websites that we enjoy with the browser, there are many more sources of information that are out there, on the web, but do not have a human-facing presentation. To consume these, you must have a program that uses their API.

Tutorial for a new application

When learning a new programming language, it is customary to start with a "Hello, World!" program.

This tutorial will guide you through this process for the KRL programming language* used with picos.

How to make money hosting picos

In the third note of an earlier post on Managing channels, we promised this post.

Basic economics

Buy low; sell high.

Running a pico engine in an AWS EC2 instance will cost a few dollars a month. Such a site could host thousands or probably even tens of thousands of picos. So, sell control of a pico for ten dollars a year and you should be able to make a profit.

Managing your KRL code for rulesets

When using PicoStack, code and data are combined within a pico. Together they represent some entity, which is responsive and reactive.

The code is written in KRL, the language you will need to learn (after having learned enough HTML, CSS, and JavaScript to get started). Since KRL itself consists of ASCII text (except in character strings and comments (where you can insert other UNICODE characters)), you can use your favorite text editor or  integrated development environment (IDE) to write your code.

Besides maintaining this code on your own machine, you will probably want to use a code repository in the cloud. This post explores possibilities.

Web API needing a token grant

Web APIs that follow the OAuth pattern need special treatment.

Besides needing a client id and client secret, API calls that do actual work require a bearer token, which is generated by a special call to the API.

So, using such an API is a two step process:

  1. Given the client id and secret, request a token
  2. Supplying the token, make the API call that does actual work
While one could do the two steps for each actual API call, it is better practice to store the token from the first call in an entity variable and then use it in each API call that does actual work.