Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion regarding HttpTransport exposed methods #543

Open
aseure opened this issue Apr 4, 2019 · 0 comments
Open

Discussion regarding HttpTransport exposed methods #543

aseure opened this issue Apr 4, 2019 · 0 comments

Comments

@aseure
Copy link

aseure commented Apr 4, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants