Why You Should Get to Know HTTP and HTTPS

January 06, 2017 by David Williams

Every time you browse to a website, one of the application layer protocols HTTP or HTTPS is in use, but several online Internet of Things platforms put HTTP(S) into use for machine-to-machine communication as well.

HTTP and HTTPS are two of the most widely used application layer protocols on the internet. Every time you browse to a website, one of the two protocols is in use, but several online Internet of Things platforms put HTTP(S) into use for machine-to-machine communication, as well.


HTTP or HyperText Transport Protocol is the application layer protocol that moves a large portion of the data around the internet. HTTPS is basically the same protocol but with a layer of authentication and encryption added to it (the S stands for secure). There are many fine articles and much documentation describing the details of HTTP and HTTPS; the purpose of this article is to discuss how HTTP and HTTPS can be used in the Internet of Things and specifically with machine-to-machine communication. For the purposes of this article, I am going to refer to HTTP, but unless specified otherwise, the same ideas apply to HTTPS.

As the name suggests, the HyperText Transport Protocol was designed to move hypertext (generally HTML) around the internet. Whenever you browse to a website, your browser creates and sends an HTTP request to the server of the website. The website takes the request and creates a response which includes the HTML that your browser takes and converts into a nice website that you can view. This description applies to most of the use of HTTP and HTTPS on the internet.

One of the great things about the HTTP and HTTPS protocols, is that they are fairly generic, and therefore easily extensible. The protocol is a request/response type of protocol where the client creates a request and the server sends a response. The request consists of the request type, the specific resource that it is being requested and a set of headers that contains extra information about the request such as which specific domain the request is going to, what kind of device is making the request, and how to handle the server-client connection once the request is complete. The response consists of a code indicating the result of the request, headers that contain extra information about the response (such as the type of server making the response and the last time the resource was updated), and the requested information.

The following two figures show an example HTTP request and response with some of the details pointed out. Here is a typical request:

Figure 1. A basic HTTP request


Here is a typical response:


Figure 2. A basic HTTP response

HTTP(S) and the Internet of Things

There is really nothing in the HTTP protocol that says the data requested must be a hypertext document and several cloud-based IoT database services take advantage of this to use HTTP as the interface to their database. These IoT databases work like this (although the specific terminology changes from service to service): the service provides users with a channel to which they can send data. This data typically takes the format of a stream of data from a sensor of some kind that periodically sends the data to the service. The service organizes and logs the data which then becomes accessible from anywhere on the internet. The service is a prototypical machine-to-machine interaction because there does not need to be any human involvement in the data streaming. Many services also include the ability to trigger actions based on the data meeting certain criteria.

Figure 3 shows a use case for HTTP in the Internet of Things.


Figure 3. ThingSpeak sensor system using HTTP to move data through the internet Image courtesy of ThingSpeak

In figure 3, the Arduino represents a sensor (or sensor system) that collects data and sends it to a cloud based, IoT database. In this example the IoT database is ThingSpeak, but there are a number of other services such as Exosite, Xively, Carriots, and Nimbits that also use HTTP(S) as their interface. The data can then be viewed from any computer on the Internet.

HTTP comes into the picture because the data is being moved around in this system via HTTP requests. The service highlighted in this figure (ThingSpeak) requires users to send an HTTP post request to their channel to send it data and an HTTP get request to obtain data from the channel. The specific requests look like this:


Figure 4. Examples of POST and GET requests to ThingSpeak. Used courtesy of ThingSpeak.

The ThingSpeak interactions shown above are easily implemented as machine-to-machine messages because it is easy to program an embedded device to send HTTP requests and manage the simple responses that it gets back. One thing to note in these messages is the api_key. This key is essentially the password to read and/or write to the channel and if HTTP requests are used to send the key, that means that anyone eavesdropping on your messages would get that key.

The obvious solution is to use HTTPS which adds a layer of authentication and encryption to HTTP. Aside from the authentication and encryption, HTTP and HTTPS messages are the same, so unless there is a compelling reason not to use it, HTTPS should be the protocol of choice for communication with an IoT platform. In some instances, the compelling reason is that the embedded microcontroller sending data to ThingSpeak does not have the processing horsepower to effectively handle the authentication and encryption necessary to use HTTPS. A workaround would be to add a proxy or gateway in between the sensor system and the cloud. For example in a wireless sensor network where each sensor uses a very basic microprocessor, a proxy could collect the data from the sensors over a local wireless network (e.g., Zigbee), and then encrypt the data before sending it out over an HTTPS connection.

HTTP and HTTPS are reasonably good protocols for machine-to-machine interactions like the ones described here. They are open standards that operate over TCP/IP and allow for customization via the headers and the data. They are not optimized for all situations though. They have a lot of overhead, so don’t work well in limited bandwidth environments and use more power when compared to bandwidth optimized protocols. These two protocols do have some big advantages though. First, they are easy to understand and implement because of their human readability. Second they are universally available; in other words, no matter where you are accessing the Internet, you will be able to use HTTP and HTTPS.


While HTTP and HTTPS may not be perfect protocols for machine-to-machine communications in the IoT, they are good enough to get you started. Many IoT database services support HTTP(S) and its ease of use means you can be up and going with an IoT system very quickly.


Featured image used courtesy of Rock1997 (own work) [CC BY-SA 4.0-3.0-2.5-2.0-1.0]