Nominate our 2022 Qt Champions!

Potentially complex network application construction

  • I'm writing an application to a RESTful API where an auth token might time out and therefore a request might fail and a re-auth might be needed. It could fail for other reasons as well, of course. It's not too hard to set it up if you assume every request will succeed. But I'm wondering if I can get some best-practice pointers on how to set this kind of thing up in a real world scenario. I don't have extensive Qt experience but understand it reasonably well.

    I'm planning to have a single method to construct and send requests, because many of the request types have similarities.

    There may also be multiple requests in progress at the same time.

    I am now thinking of maintaining a QVector<QNetworkRequest> and put the request in as it is constructed. A slot to read the reply (connected to finished() on QNetworkReply) could check the origination of the request, fetch the original request with request(), reference that to see what it was looking for, and parse accordingly. If it needs re-authentication it could do that, then try the request again. I guess I could use custom attributes of QNetworkRequest to say what type of request it was. Once it was all successful it could remove the request from the QVector.

    Seems like a bit of a mess. Is there an elegant way to set this up? Thanks!

  • I think that you should focus more on the transport protocols like TCP or UDP.
    In this case I assume that you require a stable and reliable connection, hence my advice is to look into TCP, as its structure of acknowledging received packets to the sender makes it possibly ideal to your type of application.
    The state of the connection can be monitored by the flags, so you could have something like this to check if something changed:

    QTcpSocket *newSocket = new QTcpSocket();

    connect(newSocket, SIGNAL(stateChanged(QAbstractSocket::SocketState)),
    this, SLOT(socketStateChanged()));



    void MainWindow::socketStateChanged()
    // print current state of socket
    qDebug() << newSocket->state();


    In that example the socket state is printed out every time it changes.

    I don't see the need for a QVector, but maybe I am misinterpreting your question.

  • Hmm, I don't know why I would use TCP directly instead of the QNetworkAccessManager, QNetworkRequest, and QNetworkReply classes. They seem to have pretty much what I need. I noted I'm using a REST API, so the requests will be GET, POST, PUT, and DELETE.

    I know it is hard to explain, sorry. The hairy part is keeping track of everything and re-trying requests that need it for whatever reason, preferably in a way that is self-contained within the class, and without the main app having to worry about that and send another request. (If it fails fatally for whatever reason the main app will be signaled.)

    Since QNetworkRequest doesn't seem to record the HTTP verb (method) used, I guess I have to store it in a custom attribute, and probably another custom attribute with more details on what it was doing.

  • It might be easier to just use another thread to handle requests. Then a request can take as long as it needs and send additional requests without having to go through all kinds of hoops related to asynchronous programming. How would you do it?

Log in to reply