DeepAI
Log In Sign Up

Towards a secure API client generator for IoT devices

Given the success of IoT platforms, more developers and companies want to include the technology in their portfolio. However, in the case of single board microcontrollers, the support for networking operations is not ideal, and different IoT platforms allow access to the networking submodule via different libraries and system calls, leading to a steeper learning curve. Code generators for API clients can enhance productivity, but they tend to generate universal purpose code, and on the other hand the networking primitives of IoT devices are platform specific, especially when security mechanisms such as Transport Layer Security are part of the picture. This paper presents , an API client generator developed as a plugin for the OpenAPI Generator project, which can tailor the generated code based on the IoT platform specified by the user. Our work allows to generate correct code for API clients for IoT devices, and thus can empower a developer with more productivity and a faster time-to-market for its own applications. By combining together mainstream technologies only, offers a gentle learning curve. Moreover, experiments show that the generated code has a reasonable footprint, at least with respect to the IoT devices that were used in the validation of the work. The code related to this work is available through the OpenAPI Generator project <cit.>. This technical report is an extension of <cit.>, and it integrates the information presented at the ACM SAC 2022 conference.

READ FULL TEXT VIEW PDF
08/20/2019

Memory Forensic Analysis of MQTT Devices

Internet of Things is revolutionizing the current era with its vast usag...
10/27/2018

IoT Cloud Platforms: an Application Development Perspective

With the growing number of Internet of Things (IoT) devices, the data ge...
02/22/2021

Clustering Algorithm to Detect Adversaries in Federated Learning

In recent times, federated machine learning has been very useful in buil...
04/02/2020

IoT-Flock: An Open-source Framework for IoT Traffic Generation

Network traffic generation is one of the primary techniques that is used...
09/15/2021

Anti-Tamper Protection for Internet of Things System Using Hyperledger Fabric Blockchain Technology

Automated and industrial Internet of Things (IoT) devices are increasing...
08/19/2022

Usable Security for an IoT OS: Integrating the Zoo of Embedded Crypto Components Below a Common API

IoT devices differ widely in crypto-supporting hardware, ranging from no...
09/30/2019

Optionality and Convexity in ICT Networks

Networking companies, especially the ones with the biggest market shares...

1. Introduction

Year by year Internet of Things (IoT) applications are becoming increasingly popular, and all the market segments related to IoT show no sign of slowing down (columbus2017roundup). Common use cases span from monitoring industrial machines (albano2019mantis) to hobbyist projects and home automation (javed2016building). However, industry acceptance is not as fast as it could be, and ”Security, IT/OT integration and unclear ROI are the greatest barriers to IoT adoption today.” (columbus2018roundup)

One fundamental feature of IoT devices is the capability of communicating over the Internet, and in fact most IoT definitions (berte2018defining) are focused on this characteristic. The plethora of use cases of the IoT raises the need for both an easy way of sending and receiving data across the internet, but also for doing it securely, since the steeper barrier for IoT market acceptance is in fact security (columbus2018roundup). Luckily, most modern IoT devices come with built-in internet connectivity. Augmented with a proper support by the operating system, this can take care of the lowest layers of the ISO/OSI stack (palattella2012standardized).

Even though current research trends are looking into novel security techniques (see for example (frimpong2020secon)), Transport Layer Security (TLS) is the de facto standard technology for keeping an Internet connection secure and safeguarding any sensitive data that is being sent between two systems (SSL_TLS). The protocol requires two cryptographic keys, one to be shared publicly and one to be kept private. A client needs to know in advance the public key for the specific server in order to verify its identity and set up a secure connection, or as an alternative a public key certificates can be sent from the server to the client. In the latter case, which is the most common, the client can verify that the certificate is valid according to a Certification Authority (CA) that installed a root certificate on the client beforehand, thus validating the identity of the server, and then the client can extract the public key of the server from the issued certificate to start communicating with it securely. (tlsmastery)

With regards to the application layer, many modern systems use Representational State Transfer (ReST) Application Programming Interfaces (APIs) for the communication between server and client, since it provides many benefits such as interoperability (costa2014evaluating). Most often than not, a REST API is built upon the Hypertext Transfer Protocol (HTTP)(yannakopoulos2003hypertext), and on its secure sibling HTTP Secure (HTTPS), which exchanges HTTP messages and protects them using TLS before sending it over the internet. When an IoT device is part of the scenario, support for HTTPS must take into account that servers use different certificate providers, and the client needs to store the corresponding root certificate to verify the identity of the server and build up a secure connection. This can represents a problem since there is no guarantee that there is not enough flash memory for all the existing root certificates in the IoT device’s flash memory.

Software developers or companies who implement API clients on IoT devices often develop the code for a specific microcontroller, since the HTTP/HTTPS libraries are microcontrollers-specific and for example the code developed for a ESP32 (Esp32HTTPClient) cannot be used ”as it is” on a ESP8266 (Esp8266HTTPClient). Code generation can improve developers’ productivity and reduce time-to-market of applications, thus it can be an attractive option for software developers and companies alike. However, existing code generators for microcontrollers do not support networking very well. In fact, these generators focus on the generation of more universal purpose code, but on the other hand the networking primitives of IoT platforms are hardware specific.

This report describes the creation of cpp-tiny-client, an API client generator tailored for IoT devices, which was developed as a plugin for the OpenAPI Generator project(OpenAPIGenerator). The code generator allows to establish both HTTP and HTTPS connections with the server, and it supports potentially multiple CA root certificates – if the microcontroller’s flash memory is large enough.

The report is structured as follows. Section 2 provides background information on microcontrollers, code generation and related tools, and culminates by selecting which of them are taken into account into the development work – and why. Section 3 and Section 4 describe the design and the implementation of the cpp-tiny-client generator respectively, the first being useful for a user of cpp-tiny-client, and the second for a developer interested into extending it to more microcontrollers. Section 5 documents the validation process used for the cpp-tiny-client, with a particular focus on the memory footprint. Section 6 concludes the paper and proposes future work to overcome current limitations.

2. Background Information

This section describes building blocks that could be put together to create a code generator solution for IoT devices. Later on, the section surveys existing approaches to code generation, not only to compare with our proposed idea, but also to identify which one to extend to realize cpp-tiny-client. Finally, this section concludes by taking decisions on what to integrate to design and implement cpp-tiny-client.

2.1. Which IoT platform and tools?

The IoT platform and its development environment have an impact on how the (generated) code must be structured and will be deployed to the IoT devices. Even though many microcontrollers hit the market every year, the IoT platforms that are leading the market are not so many. Arguably, the Arduino platform is very popular, and well supported by many IoT devices manufacturers. For example, Espressif Systems creates popular microcontrollers (EspressifWorldLeading) that support two different frameworks, Arduino and ESP-idf. The following discussion revolves around the Arduino Integrated Development Environment (IDE) and PlatformIO, which are good development environment candidates for cpp-tiny-client.

2.1.1. Arduino IDE

(ArduinoIDE)

Developing a project for Arduino is often done with the Arduino IDE. It is open source and requires little setup. To create a project, the user selects its Arduino model, which serial port it is connected to, and can start coding. While this process is simple, it also lacks some essential features for developing a larger project in a group of people. Primarily, Arduino IDE has no version control integration, no code debugger, and no intellisense. Arduino IDE projects are developed in the Arduino language, which is a subset of C++.

2.1.2. PlatformIO

(PlatformIO) is a ”cross-platform, cross-architecture, multiple framework, professional tool for embedded systems engineers and for software developers who write applications for embedded products” (WhatIsPlatformIO). PlatformIO supports many different platforms and frameworks, including Arduino. This tool allows the option of being integrated in various IDEs, however, on its website it is recommended to use it via the PlatformIO Visual Studio Code extension. A PlatformIO development project includes a platformio.ini file where the environment, library dependencies, etc. are specified. PlatformIO projects are developed in the C++ language.

2.2. Which IoT microcontrollers?

Espressif Systems creates popular microcontrollers (EspressifWorldLeading) that support two different IoT platforms, one of them being Arduino.

While many microcontrollers come with very limited amounts of flash memory and RAM, the comparatively larger memory of the ESP family presents the user with more options. Table 1 shows a comparison of the ESP family versus two popular microcontrollers by Arduino (ArduinoMegaSpecs; ArduinoUnoSpecs). Both the ESP32 and ESP8266 come with a much bigger memory pool. This is also the case, when comparing with other popular microcontrollers of the same price range from other vendors. The Arduino Mega also comes without integrated WiFi, but with the option of adding this functionality externally.

ESP32 ESP8266
Arduino Uno
WiFi Rev 2
Arduino Mega
2560 Rev 3
WiFi Yes Yes Yes No
Flash
memory
1-16MB 1-16MB 48KB 256KB
RAM 512KB 160KB  6.2KB 8KB
Table 1. Comparison of popular microcontrollers

2.3. Which External Libraries can be Useful?

Two external libraries appear to cover interesting functionalities to support code generation for API clients. Their purpose is to communicate with a server and send or receive data in JSON format.

2.3.1. HTTPClient and ESP8266HTTPClient

Both libraries are used for making HTTP requests. They have the same interface, but are developed for the ESP32 (Esp32HTTPClient), and ESP8266 (Esp8266HTTPClient) microcontroller respectively. The libraries are written in C++ and developed by Espressif Systems. They are part of Espressif’s Arduino library package, which is based on the Arduino Core library. The libraries are able to establish TLS connections, but they expose a different interface for this use case. HTTPClient needs a root certificate to establish an TLS connection, whereas the ESP8266HTTPClient needs a x509 fingerprint.

2.3.2. Steinwurf Bourne

Bourne is a C++ JSON read/write library developed by Steinwurf (SteinwurfBourne). Data is encoded as JSON as it is transferred between client and server, and an API client can use Bourne to either convert data that is being sent to the server into a JSON format or parse JSON received from the server into appropriate variables and data structures.

2.4. Generating Code for IoT Platforms

In general, existing API code generators are found wanting with regards to their support for networking for IoT devices, as networking primitives of microcontrollers are hardware specific. However, some code generators are easier than others to be integrated in a development process for IoT devices.

2.4.1. ThingML

(ThingMLpaper) is a modelling language, with tools for multi-platform code generation (WhatIsThingML). The approach involves modeling a distributed system in the ThingML programming language, and using this model to generate code and UML diagrams. ThingML has plugins to communicate across different parts of the distributed system, but no plugin for communicating through HTTP Requests. On the other hand, an example of how to integrate HTTP requests on Arduino in ThingML is shown on their public Github repository (ThingMLServerExample). It appears that the user has to implement plain Arduino code for networking, and ThingML is wrapped around the plain C code developed manually. This approach does not satisfy the idea of using code generation to simplify the development of code on IoT devices since it requires to have deep knowledge of the particular IoT platform being used and of its networking libraries.

Still, it could be possible to spend significant effort on ThingML to overhaul its design, implement a plugin for network logic, and end up with a reasonable solution for API code generation. However, according to the paper describing ThingML (WhatIsThingML) and its website, the last drawback of ThingML is that it has only been used by students, and it is not widely used in the industry.

2.4.2. CAPSml

(CASPml) is a model driven code generation framework. This code generator is based on CAPS, which is described as ”an architecture-driven modeling framework for the development of IoT Systems” (muccini2017caps). CAPS uses a graphical user interface for the design and modelling. The CAPSml generator uses the software model output from the CAPS software to generate a ThingML language specification of the modeled system. This allows users to generate their systems with the ThingML framework using the graphical design approach of CAPS. CAPSml looks promising since it is designed for IoT development. However, it is based on ThingML, thus it raises its same concerns.

2.4.3. ArIA

(ArIA) is another model driven code generator built on top of CAPS. ArIA generates plain Arduino code from a model in CAPS. This allows the user to design behavior in CAPS, which has a graphical user interface, instead of coding directly in the Arduino environment. The ArIA paper shows an example, with a server component, which sends data to a mobile application (illustrated in their paper by Figure 2 of (ArIA)). The paper does not specify how communication is done on Arduino, and in particular whether it is via a serial port or networking, and if it does this securely. Finally, this code generator inherits the same issues of ThingML, and it lacks documentation.

2.4.4. Asm2c++

(asm2c++) is a tool which can automatically generate C++ code for Arduino. The code is generated based on an Abstract Syntax Machine, more specifically a specification written in Unified Syntax for Abstract State Machine (UASM). The purpose of generating C++ code based on this specification is the rapid design of embedded devices, while retaining a high level of correctness through validation and verification of the syntax. There is no future work planned for generating code for network protocols and sockets, and the URL for downloading the source code of ASM2C++ references to a non existing page.

2.4.5. OpenAPI Generator

(WhatIsOpenAPI) is an open source project that has the goal of generating server stubs, API clients and API documentation based on an OpenAPI Specification (OAS) (OpenAPISpecificationDesc). An OAS allows the user to describe their entire API, including endpoints, input/output parameters for operations, authentication, and more. An OAS can be written in a YAML or JSON format. The OpenAPI Generator project contains API generators for over 40 programming languages, and by the way it supports API client generation for languages commonly used in microcontrollers such as C and C++.

Users can define an interface with an OAS, and then generate both API clients and server stubs. These components provide corresponding functionality, services, and models as specified, and the generated code can be imported into the users project. The consortium managing and developing OpenAPI Generator is very active, and the documentation of the code generator is great, but the OpenAPI Generator can not generate clients for microcontrollers, since generated code refers to libraries that are not supported by microcontrollers. According to the OpenAPI Generator website (OpenAPIGeneratorUsers), the OpenAPI Generator is used by more than 100 companies in the industry, among them Arduino Inc.

2.4.6. Apigend

(laso2020deployment) is built on OpenAPI Generator and allows to generate client APIs for Android and the ESP32 microcontroller. The solution allows the ESP32 to make requests mediated by the Message Queue Telemetry Transport (MQTT) protocol to a server. Albeit interesting, the paper does not mention how security is implemented nor how to adapt the code generator to other IoT platforms, and in particular what to do if the target platform does not have a MQTT library available, or when a MQTT broker cannot be part of the architecture.

2.4.7. AutoIoT

(nepomuceno2020autoiot) applies a simplified version of Model Driven Engineering to allow developers without experience in the technique to generate the server-side code to support IoT-based applications. The IoT devices can communicate with the server using MQTT, HTTP or WebSockets, but the solution is directed to the developers of servers that receive data from IoT devices, and it considers that the IoT devices are programmed in the traditional manual way.

2.5. What to Use for cpp-tiny-client

The ESP family of microcontrollers was chosen as the first IoT devices to be supported by cpp-tiny-client, because of their popularity, ease of use and connectivity possibilities. For example, they are already used for industrial monitoring i.e. in products by norvi (norviCorp). Moreover, while many microcontrollers come with extremely limited amounts of flash memory and RAM, the comparatively larger memory of the ESP family (see Table 1) allows the user to build more complex applications. In particular, the focus is on the ESP32 and the ESP8266 microcontrollers, which come with integrated WiFi and allow to perform HTTP and HTTPS requests by means of the HTTPClient (Esp32HTTPClient) and ESP8266HTTPClient (Esp8266HTTPClient) libraries respectively.

For serialization and deserialization of JSON, the Steinwurf’s Bourne library was chosen due to its ease of use and because it can be included in a development project as a single C++ file. cpp-tiny-client was built on top of the OpenAPI Generator project, since the project is widely used in the industry (OpenAPIGeneratorUsers). Generated code is compiled using PlatformIO, since it appears more flexible than other development environments for the Arduino microcontrollers.

Figure 1. Architecture of client (green) and server (grey) system using the HTTP protocol

3. Design

cpp-tiny-client was designed to be a plugin for the OpenAPI Generator project, and Figure 1 depicts the grand vision for the solution. A microcontroller (on the left) communicates via the HTTP (or HTTPS) protocol with a server, which has access to a Database, e.g. to save received data on permanent storage. The green box is the code that is executed on the IoT device, and it is (partly) generated by cpp-tiny-client from the OAS. The grey box is the code executed on the Server, it can also be generated using OpenAPI Generator, but it is not in the scope of this work.

Figure 2 shows an abstract representation of the code of the generated API client. In OpenAPI Generator’s terms, the Generated Models are the data structure used in the API interactions. The Generated Services provide function calls that are used to perform GET, POST, etc operations on the remote server. All services inherit from AbstractService, which is a class that is added to all generated solutions. AbstractService handles network logic, and moves the low-level networking code out of the files that the developer can decide to modify. All the service requests return a Response object, which contains an HTTP status code and a data structure (Generated Model) of a type that depends on the endpoints return type.

Figure 2. Architecture of generated code
[env:esp32]
platform = espressif32
board = nodemcu-32s
framework = arduino
lib_deps =
    github.com/steinwurf/bourne.git
extra_scripts =
    pre_compiling_bourne.py
Figure 3. Implementation of ESP32 environment in platformio.ini

As illustrated in Figure 1 the API client is generated based on an OAS, which can support different media types such as JSON, XML, and Images (OpenAPIMediaTypes). JSON is the only media type implemented in cpp-tiny-client. cpp-tiny-client support the HTTP request methods GET, DELETE, PUT and POST, and the request parameters can be specified as query (e.g.: /users?role=admin), path (e.g.: /users/{id}), body (used for POST methods and more rarely for PUT methods), and form (used sometimes for POST methods, and to send binary files) – meaning that header parameters are not supported yet.

An TLS connection is necessary for HTTPS. To validate the identity of the server and establish the TLS connection, the IoT device needs the CA root certificate corresponding to the certificate of the server. Because of the flash memory constraint, it is difficult to store many root certificates on the microcontroller, and the user has to select manually one or more certificates to be included in the PlatformIO pipeline.

When generating an API client with cpp-tiny-client, it is possible to specify the targeted microcontroller (the default microcontroller is ESP32), and the generated code will be tailored for the specified IoT device. The file platformio.ini is required by PlatformIO to specify the microcontroller environment and external libraries such as Steinwurf’s Bourne library, and it is generated based on the board111nodemcu for ESP32 and d1-mini for ESP8266 selected for the code generation. An example of platformio.ini file for the ESP32 is shown in Figure 3. The file can be modified by the developer to match different hardware.

The ESP32 and ESP8266 use different HTTP libraries. The generator outputs the proper code for either HTTP or HTTPS and setup the platformio.ini configuration file, based on the targeted microcontroller. HTTPS is supported on ESP32. The ESP8266 uses x509 fingerprints (Esp8266HTTPClient_Example) for TLS connections, and its support is not implemented yet.

for tree=font=, grow’=0, folder indent=.9em, folder icons, edge=densely dotted [cpp-tiny-client [lib [models] [services] [TestFiles] ] [src [main.cpp, is file] ] [test [RunTests.cpp, is file] ] [platformio.ini, is file] [README.md, is file] [root.cert, is file] [pre_compiling_bourne.py, is file] ]

Figure 4. Folder structure of API client

Figure 4 reports on the structure of the code for the generated API client. The files in the models folder describe non-primitive data types used for the HTTP requests and response. services contains methods to interact with API endpoints on a server. The root.cert file is the copy of the certificate fed by the developer. It is possible to ship to the IoT device more than one certificates, whose names will be root1.cert, root2.cert, etc. The file platformio.ini is used by PlatformIO to specify the microcontroller environment and external libraries during the compilation process. The files in the TestFiles folder are used to validate generated code, and as examples for the usage of the generated library. Finally, since Bourne JSON uses 11 C++ functions that are not compatible with Espressif, the pre_compiling_bourne.py file gets executed by PlatformIO at compile time to ”fill the gaps” and to make Bourne JSON compatible with Espressif.

4. Implementation

The core of OpenAPI Generator is composed of an engine and a set of Mustache template files (Mustache5), which use placeholder tags that can be replaced with zero, one or multiple values given a context.

The OpenAPI Generator engine is written in Java. The codebase contains a code generator class for each language (python, java, etc) or framework (flask, spring, etc) that OpenAPI Generator targets, plus a few common classes used for example to preprocess the OAS.

The OpenAPI Generator engine parses OASs as tree data structures, and moves between its nodes while processing the Mustache templates. Let us consider that a OAS was parsed into the following data structure, represented as JSON for sake of readability:

{
  "city": "Madrid",
  "museum": [
    { "name": "el Prado" },
    { "name": "Cerralbo" },
    { "name": "Sorolla" }
  ]
  "x-hot": true
}

The following Mustache template:

The city {{name}} has
the {{#museum}}{{name}} Museum, {{/museum}}
and much more.
{{#x-hot}}
And it’s hot in the Summer!
{{/x-hot}}

will produce the following:

The city Madrid has
the el Prado Museum,
the Cerralbo Museum,
the Sorolla Museum,
and much more.
And it’s hot in the Summer!
begin(std::string url)
{
    {{#isESP8266}}
    http.begin(client, url);
    {{/isESP8266}}

    {{#isESP32}}
    http.begin(url, root_ca);
    {{/isESP32}}
}
Figure 5. Implementation of network logic in AbstractService.h

All generators are based on the DefaultCodegen class, which provides hooks for each part of the generation process. The users of cpp-tiny-client can specify the targeted microcontroller through a Command Line Interface (CLI) option, currently the available options are ESP32 and ESP8266, and the option is parsed through the cliOptions hook. This option is used in AbstractService to differentiate between the network logic for the two microcontrollers. The services use the same method begin, inherited from AbstractService, to initializing a request, but it is populated with a different network logic based on the microcontroller at hand. Figure 5 shows a simplified code snippet of how Mustache is used to differentiate between the two controllers. The interface of the ESP8266 needs a network client to make an HTTP handshake, whereas the ESP32 handles network connections internally, and makes the HTTPS handshake with a certificate given as input.

The CLI options are also used to set the microcontroller environment in platformio.ini. A PlatformIO environment for the ESP32 is shown in Figure 3. The platform, board and framework properties need to be set based on the targeted microcontroller. The lib_deps property is used to import the Bourne JSON library.

Espressif controllers use an older version of C++, which clashes with what the Bourne JSON library expects. To make the latter compatible with the compiler, the Bourne library was modified with a #define _GLIBCXX_USE_C99 1 to parser.cpp and json.cpp. This and other operations are performed by the pre_compiling_bourne.py script, which visits the two files and modify them for the sake of compilation against the Espressif controllers.

To add support for a new microcontroller to cpp-tiny-client, (i) the name of the controller needs to be defined in cliOptions and processOpt; (ii) the network logic for the new microcontroller needs to be implemented in AbstractService.h and in the service templates; and (iii) a platformio.ini must be generated to specify platform, board and framework properties.

5. Validation

Figure 6. UML Class diagram for the PetApi service

To validate the correctness of the generated API client, we considered both the generated models and services. Subsection 5.1 details how we used the official OpenAPI’s test server to test the generated client code. Subsection 5.2 analyzes the memory footprint of the generated code.

5.1. API Test

The validation code was generated based on the Petstore OAS, and the generated code was validated against the official OpenAPI Petstore test server222https://petstore3.swagger.io/. Figure 6 and Figure 7 show the UML class diagrams for one of the models and one of the services respectively.

Figure 7. UML Class diagram for the Pet model

From the Petstore OAS, a PetService, OrderService and UserService classes were generated. The tests were performed by calling methods in these generated services, and by comparing the output of generated code with the result of API requests using the CURL tool (CURL).

Index Endpoint HTTP Method Description
1 /pet PUT Update an existing pet
2 /pet POST Add a new pet to the store
3 /user/createWithList POST Creates a list of users with given input array
4 /pet/{petId} DELETE Deletes a pet
5 /pet/{petId} GET Find pet by ID
Table 2. Description of tested endpoints

Table 2 describes the endpoints used for testing, and Table 3 describes the input each service method is called with and the expected output from the server response.

Index Input Expected Output Parameters
1 Pet object Pet object Body
2 Pet object Pet object Body
3 ListUser ListUser Body
4 int64 petId String Path param
5 int64 petId String Path param
Table 3. Input and output for each endpoint

The test code was executed on an ESP32, and the server response was logged in the terminal. By comparison with the execution of the CURL tool, it was possible to assert that the code was behaving correctly.

5.2. Memory footprint

As previously discussed, the memory consumption on microcontrollers is of concern. Thus, we analyzed the memory footprint of our API client generated for an ESP32, using the PlatformIO’s memory analysis tool.

Figure 8 shows the flash memory footprint for a simple project using the different libraries used for the ESP32. Numerical data are also reported in Table 4. An empty project occupies 196 KB. A project with Bourne JSON and HTTPClient weighs 688 KB, and an API client generated with the petstore OAS uses 1280 KB, hinting that the code generated by cpp-tiny-client has a small footprint, and that 4 MB of flash memory of an ESP32 is enough to include reasonably complex business logic. However, the tests show that the generated code can only be used by microcontrollers whose memory is at least 688KB.

Figure 8. Memory footprint against what got included into the source code

6. Conclusions & Future Work

This report documents the design and implementation of cpp-tiny-client, an API client generator for IoT devices. The generator is a plugin for the OpenAPI Generator project, and it is compatible with ESP32 and ESP8266 microcontrollers. cpp-tiny-client uses PlatformIO as build platform, and the generated code uses Espressifs’ HTTPClient and Esp8266HTTPClient libraries for HTTP requests and Bourne JSON for serialization and deserialization purposes.

Contains Flash memory used (KB)
Empty project (base line) 196
Bourne 418
HTTPClient (Arduino) 518
HTTPClient (Arduino) & Bourne 688
Entire generated API client 1280
Table 4. Memory consumption overview

cpp-tiny-client is in its beta phase for evaluation by users. Future work aims to support HTTPS for ESP8266, by distilling a x509 fingerprint from certificates, as needed by the ESP8266HTTPClient library. Some more work is required to support request parameters encoded as headers, and use it for basic authentication support. Currently, the API clients generated by cpp-tiny-client can only use the JSON media type. We plan to add native support for other media types, such as the image media type, to cover for example the use case of a IoT device controlling a camera and posting collected images to a remote server.

The current structure of cpp-tiny-client hints that it is possible to support further microcontrollers. With the vast differences in microcontroller architectures, available RAM and flash memory, it is not likely that the same API client can be compatible with all platforms. Rather, future work would consist of creating more sub-generators, each supporting their own branch of microcontrollers, for example by including the libraries necessary to support the particular architecture. A place to start, would be to make an MbedOS API client generator, which is a different popular open source framework for microcontrollers (MbedOS). MbedOS has an HTTP request library (MbedOSHTTPRequests), similar to the HTTP request libraries used in Arduino in cpp-tiny-client. This effort would provide OpenAPI Generator with a solid foundation for generating API clients for diverse microcontrollers, which can hopefully lead to further development on the code generator.

Acknowledgment

Research funded in part by the European Union through the Horizon 2020 projects DomOS (grant agreement 894240) and FEVER (grant agreement 864537), and by Innovation Fund Denmark project FED (grant agreement 8090-00069B).

The work was supported by the OpenAPI Generator committee, and in particular by its leader William Cheng, which has evaluated the proposed cpp-tiny-client generator in its initial form. Thanks to Steinwurf and Espressif for their open source libraries.

References