Suggestion to using QNetworkReply in a webAPI

[IMAN4K]

Hi there.
I'm developing a web API (HTTP) with QtNetwork module.
Let's assume we have an interface called API and a method called details that suppose to give detail to the user :

class API :public QObject {
public:
	API(QObject *parent = 0) :QObject(parent) {
		_manager = new QNetworkAccessManager(this);
	}

public slots :
	void details(const QString name) {
		// Making a QNetworkAccessManager::get(...) here
		// and getting answer in a separate slot -> onDetails(..)
	}

	void onDetails(QNetworkReply *reply) {
		// Get information and probably emit a signal to give the detail
		// for example -> emit detailsSignal(reply->readAll())
	}

private:
	QNetworkAccessManager *_manager = nullptr;
};

But here is my question could we do the details operation without the slot onDetails ?
Maybe a silly question !
I mean we should simply using the api by just calling the details like this :
QString details(const QString name);

[SGaist]

Hi,

So basically you are trying to turn asynchronous operation synchronous ? In the case of a REST API, it's not the best idea.

You can use lambdas to avoid having to create onDetails and other parsing slots which should be private anyway. It doesn't make sense your public API.

[jsulm]

@IMAN4K said in Suggestion to using QNetworkReply in a webAPI:

QString details(const QString name);

If you want it like this then implement it like this (@SGaist pointed out that it is not a good idea to make this synchronous).
I don't know why you think you could need a slot here. You probably mean a signal to notify the user that the result is there - but if details() call is synchronous and returns the result then there is no need for a signal.

[IMAN4K]

Well i was looking for a way to make details() synchronous and simply use it anywhere in our code:

void getDeTails() {
       QString dt = details("someone");
}

But it seems in our REST API it is not a good way as @SGaist point out (also in case of using threads) so we're going to do that in a normal way :
Having method void details(QStringname);` and after invoking it waiting for an appropriate signal from API class to get the results
If i'm right about all this or you have a better idea i'm looking forward to it.

[SGaist]

Yes: don't wait.

What would be your use of details ?

You can also use a cache. If details is something that won't change for a given object, load it once and then re-use what was loaded.

[IMAN4K]

@SGaist
Actually the details(const QString &packageName) suppose to give information about the android packages in google play store (each response nearly contain 50KB data) so we're going to use it a lot and also cash the responses during application run time.
Whenever we call it we should wait for the signal to catch the package info if it was not cashed before

[SGaist]

Which API are you calling ?

Because it sounds like you should rather have a method that grabs all the information about a package, process that and pass it further your application rather than having a call for each and every piece of data otherwise you'll be likely making a lot of redundant calls.

[IMAN4K]

@SGaist
It's an unofficial API.
Yest it does.
details(..) method are responsible for sending only one request and then extracting all information from that single reply.
In other word for getting a package details we just send one query to the server and process the result (+ cashing the processed result) so there is no redundant calls.

[jsulm]

@IMAN4K You could just emit a signal after getting the data and processing it.