@@ -99,13 +99,13 @@ only difference is the API.
99## Motivation and Req vs other libraries
99## Motivation and Req vs other libraries
101*This section is my opinion and it contains criticisms of other well-known
101*This section is my opinion and it contains criticisms of other well-known
102−libraries. If you're user/fan of one of these libraries, please remember not
102+libraries. If you're a user/fan of one of these libraries, please remember
103−to react aggressively and respect the fact that I may have different views
103+not to react aggressively and respect the fact that I may have different
104−on API design from yours.*
104+views on API design from yours.*
106−I have spent time to write the library because sending HTTP requests is such
106+I have spent time to write the library because sending HTTP requests is a
107−a common thing and still there is no high-level library for that in Haskell
107+common need, but there is no high-level library for that in Haskell that I
108−that I could use with pleasure. I'll explain why.
108+could use with pleasure. I'll explain why.
110First of all, there is `http-client` and `http-client-tls`. They just work.
110First of all, there is `http-client` and `http-client-tls`. They just work.
111I have no issues with the libraries except that they are too low-level for
111I have no issues with the libraries except that they are too low-level for
@@ -123,9 +123,9 @@ API”, it's mostly the same as vanilla `http-client` in spirit/approach and
123just adds `conduit`-powered functions to perform requests and allows to use
123just adds `conduit`-powered functions to perform requests and allows to use
124global implicit `Manager` (Req does the same). If I tried to frame what
124global implicit `Manager` (Req does the same). If I tried to frame what
125exactly I don't like about `http-conduit` in words, then it would be “the
125exactly I don't like about `http-conduit` in words, then it would be “the
126−way requests are constructed”. You set, set, set instead of *being forced*
126+way requests are constructed”. You *set* parameters instead of *being
127−to declare necessary bits and *being allowed* to declare optional bits in a
127+forced* to declare necessary bits and *being allowed* to declare optional
128−way that their combination is certainly valid. Also, with `http-conduit` you
128+bits in a way that their combination is valid. Also, with `http-conduit` you
129parse request from a string without the protection of TH that otherwise
129parse request from a string without the protection of TH that otherwise
130saves the day as in Yesod.
130saves the day as in Yesod.
@@ -152,17 +152,9 @@ will no longer be valid after that function returns”. There are valid uses
152for sessions, but the point is that they are just too inconvenient for
152for sessions, but the point is that they are just too inconvenient for
153common tasks.
153common tasks.
155−It's funny that one client I worked for had to invent his own little wrapper
156−around `http-client` just because he could not possibly use `wreq` and
157−`http-client` and friends were too low-level. The previous paragraph is
158−extracted from a talk with a Haskell developer who works for that client. I
159−thought to myself “something is wrong with HTTP client libraries in Haskell
160−if they had to make a wrapper”.
162−What else? I used `servant-client` a couple of times but the amount of
155+I used `servant-client` a couple of times but the amount of boilerplate it
163−boilerplate it requires is frightening. If you have several query
156+requires is frightening. If you have several query parameters, and you use
164−parameters, and you use just one of them, good luck passing lots of
157+just one of them, you'll have to pass lots of `Nothing`s.
167## Unsolved problems
159## Unsolved problems