If a web service/API supports REST it’s called RESTful, this means it sticks to some common architectures so many programming languages can work with it.
The vast majority of online APIs are RESTfull
The number one reason you'll be using REST is that REST runs over HTTP, so any device that is on the web can use a REST API.
For example, a single board computer with Linux on it, or a cellular module, will already have a TCP/IP or HTTP stack built in. You've got an easy way to hook into a wide variety of services, both for storing data but also to grab data!
Also, many applications for IoT are about the “state” of device, and that’s why REST is used so much. Say you have a light-bulb that you are making IoT. The light-bulb has a state - whether it's on or off. The light-bulb can transmit it's state state “I’m a light, I am on” with a GET request to http://www.server.com/lightbulb/3292 (for lightbulb # 3292). You can also PUT the state back to that URL to turn the bulb on, or off. In these examples the programming and model fit the model of the device you are internetifying!
OL, so we’re done, this solves everything for IoT, just use REST and that’s it? Not so fast! In fact, that’s the problem, with REST it’s ALL request / response, this means every time you want to do something you need to request it and get the response. That can lead to tons of requests, lots of data usages, battery drain, and slow responses.
Surely there’s another way?
As you’ve seen from the TRANSPORTs episode, some of our transports like cellular or LoRa, you end up paying per byte, per message, or working with a very restrictive bandwidth. In those IoT transports, you’ll want a simple & lightweight protocol with push and pull.
Let’s take a look at a few more options!