Add support for async-rest?

[ioquatix]

It's a RESTful client implementation that follows the REST thesis.

https://github.com/socketry/async-rest

Feel free to close this issue if irrelevant.

[wing328]

@ioquatix thank for the suggestion. #3564 should make it easier to add another HTTP library support.

[wing328]

#3564 has been merged into master.

Would you have time to contribute the enhancement (async-rest support)?

[wing328]

Only 3 files need to be modified. I can get it started and you can fill in the blanks.

[ioquatix]

I don't have time for this right now.

However, it seems like an interesting idea.

async-rest is pretty opinionated and while I think it's in a good space right now, I don't mind changing it as I understand the problem domain better. What I mean by that, is that it isn't a generic HTTP client, but it is modelled after the REST thesis.

What I find fascinating, is how bad - inconsistent - and messy - many web interfaces are. I've implemented two: cloudflare and async-slack recently.

Even thought they are both web interfaces, they are both very different.

For example, while cloudflare uses a non-200 status code for errors/failures, slack uses 200 OKAY with embedded JSON which contains the error message (if any).

Because of this, and other similar issues, it becomes very difficult to make async-rest as a consistent set of hooks for building out other interfaces. Which, because it's modelled after the REST thesis, is disappointing, because it means people are building decidedly orthogonal interfaces (e.g. not using HTTP status codes, using strange mechanisms for request/response).

Even some more crazy interfaces do things like HTTP www-encoded form parameter called json=$json_encoded_request_parameters, rather than just using the post body.

So....

Where am I going with this?

async-rest is kind of pure approach, based on the REST thesis. But many interfaces don't fit with that, because they are badly designed. So, the interesting thing here, is if we can model those interfaces automatically - and how does it look - because if you can figure that out, it would be amazing. Even to the point of identifying semantic conflicts between the defined interface, how it should be used, and how it fits with the REST thesis.

Surely you have some feedback about that.

[wing328]

I don't have time for this right now.

That's ok. Let's see if anyone from the community has time to work on this enhancement.