The Internet of Things (IoT) refers to devices that collect data from their given environment and transmit this data to servers over the Internet. The difficulty with making requests comes in the fact that IoT devices are typically implemented with microcontrollers to reduce energy consumption and cost. The use of microcontrollers means that the abstractions for making Internet requests, like those available in web browsers, are not available. There is, therefore, the need to implement these requests “manually.”

HTTP Requests

If most of your experience with the Internet comes from web browsers, there is a good chance you have never seen an HTTP request of the form below:

 
GET	/doc/sweet.html HTTP/1.1
Host: www.sweetcode.io
Accept: image/jpg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: sweetagent
Content-Length: 23
 
post=IoT&author=stephan

If you have some experience with server-side programming, you may recognize the request above as a GET request by looking at the first line. If you have no such experience, then what you need to know for now is that the request above is what a GET request looks like in your browser’s backend. We’ll take a more detailed look at this request as well as the format of an HTTP response.

HTTP Request Breakdown

As mentioned previously, the first line of the request specifies the type of request in use. The two most common request types are GET and POST requests. GET requests tend to be used to obtain resources from servers, and the GET data is added to the URL. POST requests are used to send data to a server, and the POST data is not added to the URL. You can get more information on GET and POST requests from w3schools to become more acquainted with these requests. The text after the name of the request specifies the directory of the resource you want to access. (Note that there are other request types like PUT, HEAD and DELETE which are less common. In addition, the first line of the request is known as the request line.)

The second line of the request only specifies the URL of the host you want to access. The third line of the request details the kind of request the client will accept from the server. Using only image/jpg means the client will only accept .jpg images, while using */* indicates that the client accepts any kind of data. The fourth line specifies the language the host accepts, and the fifth line specifies the types of encoding the client is able to understand.

The sixth line specifies the user agent. This is a unique string that allows the server to identify the web browser, operating system and other parameters related to the client making the request. The seventh line specifies the length of the content to be sent to the server. The content is specified as key=value pairs, delimited by the & symbol, and must be separated from the rest of the request with an empty line. Note that the lines after the request line but before the empty line are known as the request header, and the portion of the request after the empty line is called the message body. (Note that the message body is optional.)

HTTP Response Breakdown

The code below is an example of an HTTP response.

 
HTTP/1.1 200 OK
Date: Sat, 5 May 2018 15:00:00 GMT
Server: Apache/1.3.29 (Win32)
Last-Modified: Fri, 4 May 2018 15:00:00 GMT
Etag: “0-23-4024c3a5”
Accept-Ranges: bytes
Content-Length: 14
Connection: close
Content-Type: text/html

Page 1

The first line is the status line and has information on how the server interpreted your request. HTTP/1.1 is the type and version of communication protocol, followed by the response code and a brief description of the code. Some other examples of the status line are:

 
HTTP/1.1 400 Bad Request
HTTP/1.1 403 Forbidden
HTTP/1.0 404 Not Found

The next line shows when the response was sent, and the ETag shows the version of the resource. The remaining lines are either self-explanatory or have the same meaning as in the request.

Sample Code for Tests

Finally, depending on what programming language or platform you are using, the method for sending an HTTP request will differ. The code below shows an example of making an HTTP request with an ESP8266 WiFi module programmed with the Arduino IDE. In this code, the text in the request is sent to the server over a TCP connection.

// Relays sensor readings from an ESP8266 wifi module to an IoT server
// by: Stephan N. Ofosuhene

#include
char* ssid = “”;
char* password = “”;

const char* host = “”;

String data;

void setup() {
Serial.init(9600);
delay(100);

// We start by connecting to a WiFi network
Serial.println();
Serial.println();
Serial.print(“esp -> Connecting to “);
Serial.println(ssid);

connect_wifi(ssid, password);
Serial.println(“Initialisation complete”);
}

void loop() {
WiFiClient client;
const int httpPort = 80;
if (!client.connect(host, httpPort)) {
Serial.println(“connection failed”);
return;
}

data += “data=something&moreData=stuff”;

String url = “/sweet/resource/”;

Serial.print(“POST: “);
Serial.println(data);
// Send request to the server:
client.println(“POST ” + url + ” HTTP/1.1″);
client.println(“Host: ” + String(host));
client.println(“Accept: */*”);
client.println(“Content-Type: application/x-www-form-urlencoded”);
client.print(“Content-Length: “);
client.println(data.length());
client.println();
client.print(data);

Serial.println();

delay(500); // Can be changed
if (client.connected()) {
client.stop(); // DISCONNECT FROM THE SERVER
}
Serial.println(“”);
Serial.println(“closing connection”);
delay(5000);
}

void connect_wifi(char *ssid, char *password){
WiFi.begin(ssid, password);

Serial.print(“esp -> Connecting to “);
Serial.println(ssid);

Serial.println(“WiFi connected”);
Serial.println(“IP: “);
Serial.println(WiFi.localIP());
}

Resources

https://www.evernote.com/shard/s529/sh/037f6a25-5d3b-4e4b-9244-51ba027b87b2/e3714b4674ba84d9a08b43edbcc6fd90

https://www.w3schools.com/tags/ref_httpmethods.asp