PedroFnseca/esp32-http-client

A lightweight REST API client for ESP32

Summary

ESP32-HTTP-Client is a C++ HTTP client library for ESP32 microcontrollers that parses REST, SOAP, GraphQL, and JSON-RPC responses directly into user variables rather than buffering them in memory. It is distributed as an Arduino-style library and targets IoT workloads where RAM and heap fragmentation are real constraints. The project is licensed under GPL-3.0.

What it is useful for

The library is useful when an ESP32 sketch needs to talk to web services without paying the typical HTTPClient plus ArduinoJson cost of tens of kilobytes of heap per request. According to the README's benchmark table (100 GETs against JSONPlaceholder /users), the library uses about 15 bytes of heap per request versus roughly 58 KB for the standard approach, and averages about 59 ms per request because it reuses the underlying TLS connection.

It supports four protocols out of the box:

• REST with GET, POST, PUT, PATCH, DELETE, plus query and path parameters.
• SOAP 1.1 / 1.2 with automatic envelope generation and streaming XML response parsing.
• GraphQL with queries, mutations, variables, and partial data preservation.
• JSON-RPC 2.0 with positional or named parameters, notifications, and struct mapping.

It also handles Bearer, Basic, and API-key headers, and provides a REST_JSON_MAP macro for mapping C++ structs directly to JSON in both directions, which makes it a fit for ESP32 nodes that hit cloud REST backends, SOAP enterprise services, or GraphQL gateways.

How engineers can use it

Installation is documented for both common ESP32 toolchains.

PlatformIO — add to platformio.ini:

lib_deps =
    PedroFnseca/ESP32-HTTP-Client@^1.4.0

Arduino IDE — install via Sketch → Include Library → Manage Libraries…, searching for ESP32-HTTP-Client.

A typical REST sketch looks like this (WiFi setup omitted):

ESP32HTTPClient client("https://jsonplaceholder.typicode.com");
int userId = 0;
client.get("/todos/1").getBody("userId", &userId);

The SOAP example extracts <NumberToWordsResult> straight into a char buffer, and the GraphQL example binds nested fields with dot notation such as user.name. Arrays are addressed by numeric index in the path (for example, "1.address.city" for the second element of a JSON array). Authentication helpers include client.bearer(token), client.basic(user, pass), and client.apiKey(name, key).

Two documented caveats from the README: persistent keep-alive connections retain about 45 KB of RAM for the TLS tunnel until client.end() is called, and pulling complete raw objects into an Arduino String causes dynamic reallocation that can fragment the heap, so prefer field bindings over raw extraction for large payloads. If a JSON key is missing or misspelled, the target variable is left unchanged rather than the library crashing.