Services and Tools
Inet API Examples
These examples follow the real usage paths in demo/urlimg and demo/products. They show both
the shortest convenience path and the more explicit request/response workflow used when the caller needs status inspection.
Relevant Source Files
1. Start Inet Once For The App Or Feature Lifetime
The repo pattern is to call inet_start() when the feature or application comes up and inet_finish() on teardown.
demo/urlimg does exactly that around the window lifetime.
inet_start();
/* HTTP work here */
inet_finish();
2. Whole-Body Download With http_dget
http_dget(...) is the shortest path when the caller only needs the response body. It parses the URL,
selects HTTP versus HTTPS, performs the GET, and returns the response body as a memory-backed Stream.
uint32_t status = 0;
ierror_t err = ekIOK;
Stream *stm = http_dget(
"http://test.nappgui.com/image_formats/home_02_rgba.png",
&status,
&err);
if (stm != NULL) {
/* Example from urlimg: hand the stream to image_read(...) */
stm_close(&stm);
}
In the repo, demo/urlimg immediately passes that stream into image_read(...) and updates an ImageView.
3. Manual Http Workflow
demo/products uses the explicit Http object instead of http_dget(...) because it wants to
inspect the status code before deciding whether to read the body.
Http *http = http_create("serv.nappgui.com", 80);
Stream *body = NULL;
if (http_get(http, "/dproducts.php", NULL, 0, NULL) == TRUE) {
uint32_t status = http_response_status(http);
if (status >= 200 && status <= 299) {
body = stm_memory(4096);
if (http_response_body(http, body, NULL) == FALSE)
stm_close(&body);
}
}
http_destroy(&http);
That pattern is the one to copy when you need response headers, response status, or more control over when the body is materialized.
4. Request Headers And Response Headers
The public API supports custom request headers and indexed or name-based response header lookup.
http_clear_headers(http);
http_add_header(http, "Accept", "application/json");
http_add_header(http, "User-Agent", "nappgui-client");
if (http_get(http, "/api", NULL, 0, &err) == TRUE) {
const char_t *server = http_response_header(http, "Server");
uint32_t count = http_response_size(http);
/* http_response_name(http, i) / http_response_value(http, i) */
}
5. HTTP Plus JSON Is A Natural Pairing
The products demo composes the networking and encoding layers directly: fetch the HTTP body into a Stream,
then hand that stream to json_read(...).
Stream *stm = i_http_get();
if (stm != NULL) {
PJson *json = json_read(stm, NULL, PJson);
stm_close(&stm);
if (json != NULL) {
/* use json->data */
json_destroy(&json, PJson);
}
}
This is the main design intent behind inet: produce a complete response body in the same Stream abstraction
that the rest of NAppGUI already uses.
6. Quick Existence Check
When the caller only needs to know whether a URL resolves to a successful response, http_exists(...) is the smallest API.
if (http_exists("https://example.com/file.png") == TRUE) {
/* status was in the 200..299 range */
}
Internally, this helper disables auto-redirect and checks the final response status range after a GET.
Practical Notes
- Default ports: pass
UINT16_MAXto use80forhttp_create(...)or443forhttp_secure(...). - Error model: failures surface through
ierror_t, which is intentionally coarse and backend-agnostic. - Response parsing: headers and status are parsed lazily when response accessors are called.
- URL helpers:
http_dget(...)andhttp_exists(...)rely on theencodeURL parser.