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

Start by reading HttpTransport and its executeRequestAsync overloads, then inspect callers such as getLogs() and the endpoint combinations described in the discussion. Determine whether operation-specific helpers preserve the existing POST/READ, POST/WRITE, and GET/READ flexibility; the work is done only when the API shape and any requestAsync visibility change are agreed and consistently applied.

Written by the indexing model from the issue text.