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

Beginne mit dem Lesen von HttpTransport und seinen Überladungen von executeRequestAsync und untersuche anschließend Aufrufer wie getLogs() sowie die in der Diskussion beschriebenen Kombinationen von Endpunkten. Ermittle, ob operationsspezifische Hilfsmethoden die bestehende Flexibilität von POST/READ, POST/WRITE und GET/READ bewahren; die Arbeit ist erst abgeschlossen, wenn die Form der API und jede Änderung der Sichtbarkeit von requestAsync vereinbart und konsistent angewendet sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.