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

Empieza leyendo HttpTransport y sus sobrecargas de executeRequestAsync; después, inspecciona los puntos de llamada como getLogs() y las combinaciones de endpoints descritas en la discusión. Determina si los helpers específicos de cada operación conservan la flexibilidad existente de POST/READ, POST/WRITE y GET/READ; el trabajo solo estará terminado cuando se hayan acordado la forma de la API y cualquier cambio en la visibilidad de requestAsync, y se hayan aplicado de forma coherente.

Escrito por el modelo de indexación a partir del texto del issue.