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

Bắt đầu bằng cách đọc HttpTransport và các overload của executeRequestAsync, sau đó kiểm tra các caller như getLogs() và các tổ hợp endpoint được mô tả trong phần thảo luận. Xác định xem các helper dành riêng cho từng thao tác có duy trì tính linh hoạt hiện có của POST/READ, POST/WRITE và GET/READ hay không; công việc chỉ hoàn tất khi hình dạng API và mọi thay đổi về visibility của requestAsync được thống nhất và áp dụng nhất quán.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.