[Interest] Feedback on Qt RESTful client development

Juha Vuolle juvuolle at gmail.com
Fri May 12 10:37:15 CEST 2023


(Posted originally on dev-list, cross-posting here too)

***

Hi,

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 a "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 big 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:
https://bugreports.qt.io/browse/QTBUG-112276

Thank you
Juha

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

1) Adding fetch() support in QML (a Promise based Javascript network 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 example, fetching a JSON:
   fetch("urlhere")
.then((response) => response.json())
         .then((json) => myModel.model = json)
         .catch((error) => console.log("Oh no", error)

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

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 Interest mailing list