Croatia - Flag Croatia

All prices include duty and customs fees on select shipping methods.

Please confirm your currency selection:

Croatian Kuna
Free shipping on most orders over 400 kn (HRK)
Payment accepted in Credit cards only

Free shipping on most orders over 50 € (EUR)
All payment options available

US Dollars
Free shipping on most orders over $60 (USD)
All payment options available

Bench Talk for Design Engineers

Bench Talk


Bench Talk for Design Engineers | The Official Blog of Mouser Electronics

RESTful APIs and Moving Data Across the Internet of Things Mike Parks

In part one of this blog series, we discussed that the crucial component of the Internet of Things (IoT) is decentralized communication and looked at how mesh networking could remove many of the roadblocks to achieving Industry 4.0. Once devices have a robust medium for communicating, the next challenge is getting all the devices to speak a common language.

An increasingly popular mechanism by which devices can exchange data and send commands between themselves is a framework referred to as RESTful APIs. First, let’s spell out the acronyms. REST stands for Representational State Transfer and API stands for Application Programming Interface. For those of us who consider ourselves hardware people more so than software or web developers, let’s explore a perhaps overly simplistic way to understand REST and API in an embedded electronics context. Let’s start with API. APIs are a software mechanism published by many web services as a way for third-party developers to safely interact with their systems in a controllable and well-defined manner. For example, if you’ve ever used a third-party Twitter app, then you have indirectly leveraged the Twitter API.

REST is a mechanism by which internet-enabled devices can communicate to other devices or servers by transmitting what appears to be Uniform Resource Locators (URLs)—such as—back and forth. Without getting too nitpicky, documentation found in many popular REST-based IoT development platforms APIs refer to these by the more technically appropriate title of Uniform Resource Identifiers or URI.

Alright, so let’s make this practical. Let’s say we want to create a website. On that website, we want to create a form that will allow us to toggle an LED on and off over the internet remotely.

The code snippet below gives us an idea of the Post method formatting:


<form action="" method="POST" target="placeholder">
    Tell your device what to do!<br>
    <input type="radio" name="args" value="on">Turn the LED on.
    <input type="radio" name="args" value="off">Turn the LED off.
    <input type="submit" value="Do it!">



Notice method="POST". This is an example of an HTTP method that RESTful APIs leverage. Other methods include GET, PUT, PATCH, and DELETE. In many IoT-embedded devices that provide RESTful APIs, the POST and GET methods are perhaps the two most used methods. The POST method is used to push data to a web server, and GET is a method to request data from a web server. So, in our example above, the POST method is the mechanism by which an end user's click on a website form is sent to the web server which in turn issues the appropriate command to the IoT device.

What about the GET request?  Let’s say we are an endpoint device connected to an actuator. Our decision to perform a mechanical action is dependent upon the temperature at a distant location. In this case, the endpoint would request—via the GET method—a temperature value stored on the web server.

The code snippet below gives us an idea of the GET method formatting:


WiFiClient client;

const char DeviceToken[] = "MY_ID_TOKEN";

const String httpRequest1 = "GET /api/v1.6/devices/Arduino101_MBA/temperature/values?page_size=1&token=";
const String httpRequest2 = " HTTP/1.1\r\n"
                                               "Connection: close\r\n\r\n";


For all intents and purposes, we are creating specially crafted strings that will be communicated over the device's Wi-Fi connection to a web server. The strings are the GET request that a web server recognizes and will, in turn, respond with the data in a string that will have to be parsed by the endpoint. A lightweight data-interchange format such as JavaScript Object Notation (JSON) is the preferred method to send information from the server to a client when responding to GET requests. Many embedded platforms have JSON libraries to help with the parsing.

In the code snippet below, the string variable line will hold the JSON packet that the server will send back after the GET request has been processed remotely.


String line = "";



while(client.connected()) {


This string will have to be parsed in order to extract the temperature value the web server passed to the actuator endpoint.

There are probably many software and web developers clawing their eyes out reading this as a hardware engineer attempts to describe REST. The point for fellow embedded engineers is to understand that RESTful APIs are rapidly becoming a preferred method for IoT devices to communicate given that they are highly flexible, scalable, portable, capable of handling multiple data interchange formats, arguably easier to develop with, and offer better performance than alternatives such as Simple Object Access Protocol (SOAP). In short, embedded engineers and firmware developers should have at least a working knowledge of the technology. This understanding will prove to be useful when having design discussions with colleagues who are working on associated mobile and web apps. This will help to help ensure security and interoperability are built into the product from the firmware all the way through to the cloud and mobile applications.

That’s it for now, but remember to check back for part three of this blog series when we will discuss Edge Computing and the Internet of Things.

« Back

Michael Parks, P.E. is the owner of Green Shoe Garage, a custom electronics design studio and technology consultancy located in Southern Maryland. He produces the S.T.E.A.M. Power podcast to help raise public awareness of technical and scientific matters. Michael is also a licensed Professional Engineer in the state of Maryland and holds a Master’s degree in systems engineering from Johns Hopkins University.

All Authors

Show More Show More
View Blogs by Date