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_MAX to use 80 for http_create(...) or 443 for http_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(...) and http_exists(...) rely on the encode URL parser.