Discussion regarding `HttpTransport` exposed methods

> I think introducing helpers in "HttpTransport" would make the code in callers more straightforward. Let's introduce "HttpTransport.doGet(Async)", "HttpTransport.doPost(Async)", "HttpTransport.doPut(Async)", "HttpTransport.doDelete(Async)" - performing corresponding HTTP operations and setting the call type ~appropriately (eg READ for GET, WRITE otherwise - with the possibility for "doPost" to override it to "READ", or have a doPostForRead or something like that). This would also permit to remove the necessity of giving null data on GET, (doGet wouldn't take a "data" argument). As a second step, it could make sense to make requestAsync private.

Not really sure about this one! We have lots of combination with the endpoints such as. POST/READ/data:null, POST/WRITE/data or GET/READ/data:null. I fear that introducing an helper would reduce the "flexibility" of the transporter. I would prefer to keep it like this. WDYT @Anthony Seure?
Moreover, an overload is available for null data (I forgot to use it in getLogs() :D). So you can perform an executeRequestAsync without passing "null" explicitly as data : Example: POST without data.

cc @Ant-hem @BenoitPerrot

Commencez par lire HttpTransport et ses surcharges de executeRequestAsync, puis examinez les appelants tels que getLogs() ainsi que les combinaisons d’endpoints décrites dans la discussion. Déterminez si les helpers spécifiques aux opérations préservent la flexibilité existante de POST/READ, POST/WRITE et GET/READ ; le travail n’est terminé que lorsque la forme de l’API et toute modification de la visibilité de requestAsync ont été convenues et appliquées de manière cohérente.

Rédigé par le modèle d'indexation à partir du texte de l'issue.