[Development] Feedback on Qt RESTful client development

Juha Vuolle juvuolle at gmail.com
Fri May 12 10:04:55 CEST 2023


I'm collecting thoughts on how to make developing Qt REST /client/
applications a smoother experience.

Here I'm thinking about a "typical" client application that wants to
talk with "typical" REST servers
as they exist today. As it stands today, the main options are
XMLHttpRequest on QML side and QtNetwork
classes on the C++ side (with per-application QML binding option).

REST  is a large and ~loosely defined umbrella and I'd appreciate your
thoughts - what would actually /help/?

In particular I'm interested in hearing about:
1) Current use cases and the bottlenecks/painpoints with them
2) Specifically about the seen utility of introducing a fetch() API,
see below  *)
3) Specifically about the seen utility for OpenAPI code-generation
(below), see below *)

If any thoughts, leave a comment here or here:

Thank you

*) Few of the more promising directions I've looked into are:

1) Adding fetch() support in QML. Fetch is a Promise based Javascript
API (https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)
   The reason I've picked it up is that it's a widely known JS API
which makes for quite compact and readable code.
   But - would you find this useful?

   To give an idea, fetching a JSON:
         .then((response) => response.json())
         .then((json) => myModel.model = json)
         .catch((error) => console.log("Oh no", error)

2) Providing support for OpenAPI code generation tools;  with OpenAPI
you can generate Qt client networking boilerplate code based on an API
description (https://openapi-generator.tech/)
    This would probably build on top of the existing cpp-qt-client
generator and add things like out-of-the-box QML support and build
system integration.
    The concept is well-known and sound, but do you see use for this?

3) Improving Qt OAuth2 support https://bugreports.qt.io/browse/QTBUG-113218

4) Possibly: Convenience classes for dealing with tasks around offline
operation, caching, and also possibly convenience data models.

More information about the Development mailing list