21–30 of 88 posts
If by "for humans" you mean "for programmers who mostly use JSON". I have to say I'm not sending JSON with cURL too often, compared to any other payload. And when I do send JSON it's more complex than a flat set of keys and values.
If you are sending complex JSON, it's probably stored in a file or it's the output of another program:
http PUT httpbin.org/put @/data/test.json
http -b localhost:8888/couchdb/ | http PUT httpbin.org/putEarlier quoted context omitted.
Not applicable. This is not a new standard; merely a new tool.
Replace standard with tool. Still applicable.
How about the various mail clients, office products, ftp clients, torrent clients & servers, programming languages, power drills, clothing lines, gasoline engines, kitchen knives and so on?
Tools are about innovation. Standards are about locking down feature sets so that tools can interact in a common way. The whole point of the xkcd comic is that too many standards makes it difficult to make tools, and adding yet another one-standard-to-rule-them-all usually backfires.
Another alternative, in Ruby, is HTTY - https://github.com/htty/htty
If by "for humans" you mean "for programmers who mostly use JSON". I have to say I'm not sending JSON with cURL too often, compared to any other payload. And when I do send JSON it's more complex than a flat set of keys and values.
[Edit: removed HN snarky comment]
If by "for humans" you mean "for programmers who mostly use JSON". I have to say I'm not sending JSON with cURL too often, compared to any other payload. And when I do send JSON it's more complex than a flat set of keys and values.
There is more to it than that. It provides an expressive syntax to construct all sorts of requests. You can submit forms, upload files and set headers without having to use flags. You also get syntax highlighting, ability to pipe in request data, etc. If you are sending complex JSON, it's probably stored in a file or it's the output of another program: http PUT httpbin.org/put @/data/test.json http -b localhost:8888/…
Earlier quoted context omitted.
It's not meant to be an insult on cURL. cURL is a great library/tool and supports way more than HTTP, but the command line interface simply isn't as convenient for common HTTP as it could be. The "for humans" slogan is borrowed from the underlying python-requests library and is meant to communicate that good UX is one of the top priorities of the project. Glad you like it!
I don't think it's the most obvious kind of good UX, but rather good UX for people who value expressiveness, like ruby programmers. The items that change meaning based on symbols are quick to type, but it comes at the cost of clarity. curl's paramters aren't very clear either, and since it supports more than just HTTP, it's harder to go through the man page with all that it supports. I think there's still room for on…
I tried to come up with syntax that would make the most common tasks (i.e., sending JSON objects, submitting forms, setting headers, etc) as easy as possible and also feel "natural". The reason for the chosen style is that it quite corresponds to the actual HTTP request being sent. For example, if you want to send a PATCH request with a custom header and a form field data:
PATCH /patch HTTP/1.1
X-API-Token: 123
Host: httpbin.org
Content-Type: application/x-www-form-urlencoded; charset=utf-8
foo=bar
http --form PATCH httpbin.org/post X-API-Token:123 foo=bar
Earlier quoted context omitted.
There is more to it than that. It provides an expressive syntax to construct all sorts of requests. You can submit forms, upload files and set headers without having to use flags. You also get syntax highlighting, ability to pipe in request data, etc. If you are sending complex JSON, it's probably stored in a file or it's the output of another program: http PUT httpbin.org/put @/data/test.json http -b localhost:8888/…
Why not use JSON syntax for JSON instead of introducing your own, though?
echo '{"foo": "bar"}' | http url
http url foo=bar