Given that there has to be consensus across the HTTP responses from multiple requests made by IC, even when the API receiving endpoint has idempotency in place to send an ACK the 1st request, and NACKs to the following requests, the canister originating the HTTPS outcall has no way of understanding whether there exists an ACK or not, if I understood correctly. Transformations to iron out small deltas wouldn’t work as it does with query endpoints. Am I missing something, or is HTTPS outcalls is not a fit for transacting on a REST endpoint? Cheers.
1 Like
I think you understand it correctly.
What you might be able to do is to have the transform function return an empty response in case of a successful result (either ACK or NACK, but still 2xx code). This way, consensus will always be reached. Then, if there exists any endpoint to query the state, you could issue a GET request to make sure the transaction has gone through.
1 Like
Yes, this will work indeed. So the verification work would be to iterate through the set of HTTPS responses {R} received from the POST request, extract 3rd-party assigned unique request ids into a set {I}, then call GET for each element in {I} whose results will naturally reach consensus. Then, if an affirmative result has been obtained from all these GETs, this implies the original POST received one ACK, otherwise all were NACKs. Hmm, despite the price reduction in HTTPS outcalls, all this would increase the cost by M equal to the multiplicity of https calls made by IC, not to mention the compute cycles. My biggest worry wouldn’t be cost though, let’s assume app’s quality justifies its price It’s rather the nitty gritty code that could trap at the simplest mistake. Very brittle imho, what’s your take on the reliability aspect?
My assumption above is that all the HTTP responses received from a POST request are returned as the result set, is this the case?
Unfortunately no. The results of a POST request, after applying the transform function, should be identical on all nodes. I agree this is not the best UX. But I don’t understand your cost computation. Are you updating multiple objects in one POST request? If not, then it’s one POST and one GET for each update.
Usually, API endpoints assign a unique id to each incoming request, hence one POST initiated from my canister would result in multiple POSTs from the nodes, hence mulliple unique IDs to check with a GET for each. The nodes won’t be returning the responses they each received to the canister, therefore the request IDs cannot be extracted to make follow-up GET calls for each of them, to see whether any of them got an ACK. I’m afraid the HTTPS outcalls do not provide composability for REST based transactional world out there.
Do you have a documentation of the REST service you are trying to use?
I want to take a look and think whether a solution is feasible.
Thanks so much, sent DM on its way.