So you have a "Thing" that you want to connect to the the "Internet of". How do you do that technical 'connection' part? 

If its a toaster, you could plug it into Ethernet and then run a cable to your router. 

But many things are wireless, so no Ethernet. Instead, they might use wireless protocols like WiFi (just about everything that stays in a home or business), Bluetooth classic (older, pre-BLE devices), Bluetooth LE (wireless lightbulbs, any things that connect to your cellphone), ZigBee, 802.15.4 (mesh networks, sensor nets), Cellular (e.g. vending machines, geotracking for cars, Kindles) etc..

The upshot is - while some devices are wired, there's a ton that are wireless. And honestly, wireless is pretty fun! BUT wireless means portable power, such as a battery, which means power requirements are important to think about. If we want to connect this device to the Internet, it has to connect fast, send data, and disconnect fast. And if it's using a low-power data connection protocol like Bluetooth LE, it has to be extra-careful that it doesn't have too much overhead. For cellular, where you really pay-by-the-byte, that's also important!

What about HTTP (REST)?

Chances are you're familiar with HTTP - its used for every website. HTTP is stateless, so you have to have a connection per data transfer - one connection every time you want to write data, one connection for reading. HTTP is great for huge amounts of data such as used for websites, and it can be used for IoT connections. But it's not lightweight and its not terribly fast.

Another problem with HTTP is that it's pull only - your toaster can only send data to the server whenever it wants (e.g. "Toast is done!"). If it wants to pull data from the server, it has to constantly connect and ask ("Any updates to the Toast darkness level?" "What about now?" "Anything now?") which is really data and time consuming. Pull updates are either slow (check only every few minutes) or data/power intensive (check constantly)

MQTT! So E-Z!

For that reason, MQTT is a great protocol. It's extremely simple, and light-weight. Connecting to a server only takes about 80 bytes. You stay connected the entire time, every data 'publication' (push data from device to server) and data 'subscription' (push data from server to device) is about 20 bytes. Both occur near instantaneously.

Thus we have no 'build up and tear down' overhead, and we can stream data in and out of multiple 'topics' quickly and easily. MQTT can run on top of any kind of network, whether it be a mesh network, TCP/IP, Bluetooth, etc. Since we'll be connecting to adafruit.io, the MQTT style we'll be discussing runs on top of a TCP/IP connection.

Cellular and WiFi and Ethernet all connect pretty easily to TCP/IP so that makes it easy to connect directly to adafruit.io

If you are using Bluetooth, XBee, Bluetooth LE, or another non-Internet-connected protocol & device, you will need a gateway! For example, the Adafruit Bluefruit Connect app has a BLE adafruit.io gateway for passing data back and forth.

But what if I really want to use HTTP & REST?

No problem, check out adafruit.io REST interface docs!

MQTT Broker at your service!

OK so we're using MQTT for speed and ease. Let's say you have this toaster at home (it has a WiFi chip, and is on your home network). And you have a geotracker in your car (a cellular+gps connection).

There's 2 ways you could have the two 'talk' to each other

1. Have one of the devices run as a 'server' with an IP address, so that the other sensor can connect to it at any time
2. Have a third 'server' somewhere, both toaster and car connect to that computer server and the computer sends messages back and forth.

Option #1 is in a sense, the 'least expensive' because no extra computer is needed. However, it's crazy difficult to pull off because the toaster or car have to be constantly waiting for a connection. And the other device needs to know the IP address of the listener. And then, what happens if a third device is involved?

Thus, we go with option #2 - the server that handles the messages? That's the MQTT Broker - and that's what adafruit.io is, essentially. A neutral party that your Things can connect to to send and receive messages.