Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTPie: a CLI, cURL-like tool for humans

github.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: HTTPie: a CLI, cURL-like tool for humans

#41

Post by jtmarmon »

zymhan wrote: post #38
gamedna wrote: post #22

First off, I am really surprised how often this gets re-posted to HN. https://hn.algolia.com/?query=httpie&sort=byPopularity&prefi... I discovered HTTPie a few years back and it has completely replaced curl/wget during our API development and testing.

I guess it's still growing in popularity but hasn't hit the inflection point of becoming a standard tool. The concept of an HTTP CLI seems obvious to me in retrospect, but I'm not a web developer, so maybe there's a reason this isn't as useful it would seem at first glance?

there is an http cli already. it's included in like every OS ever...it's called curl. httpie is just more user friendly

Re: HTTPie: a CLI, cURL-like tool for humans

#42

Post by peterwwillis »

scrollaway wrote: post #35
peterwwillis wrote: post #29

Earlier quoted context omitted.

"all it would be" is a gigantic wealth of new functionality that requests/urllib3 does not have (compare libcurl and urllib3 features), along with greater support, developer base, test coverage, user base, and lower tco. httpie gains a wealth of advantages and cURL gets syntax highlighting. It's hard to overstate how advantageous to httpie it would be.

You are extremely confused at which level it is beneficial to merge projects. You don't simplify things by going from one popular lib to another, especially when they both have legitimate use cases. Requests is one of Python's most highly regarded libs and a very popular one at that. Httpie is not its only user. And what you are describing is not a simple process. Gaining tests and features (what features anyway?) is…

> You are extremely confused at which level it is beneficial to merge projects.

Not really, since if you read my comments I suggested they could have been merged into cURL three years ago (after starting four years ago). It wouldn't even be a new project, it would simply be an add-on tool. And that's the point.

Re: HTTPie: a CLI, cURL-like tool for humans

#43

Post by dimino »

peterwwillis wrote: post #42
scrollaway wrote: post #35

Earlier quoted context omitted.

You are extremely confused at which level it is beneficial to merge projects. You don't simplify things by going from one popular lib to another, especially when they both have legitimate use cases. Requests is one of Python's most highly regarded libs and a very popular one at that. Httpie is not its only user. And what you are describing is not a simple process. Gaining tests and features (what features anyway?) is…

> You are extremely confused at which level it is beneficial to merge projects. Not really, since if you read my comments I suggested they could have been merged into cURL three years ago (after starting four years ago). It wouldn't even be a new project, it would simply be an add-on tool. And that's the point.

Can you restate your thesis?

Is is that HTTPie should be merged into the cURL project?

Re: HTTPie: a CLI, cURL-like tool for humans

#44

Post by peterwwillis »

dimino wrote: post #43
peterwwillis wrote: post #42

Earlier quoted context omitted.

> You are extremely confused at which level it is beneficial to merge projects. Not really, since if you read my comments I suggested they could have been merged into cURL three years ago (after starting four years ago). It wouldn't even be a new project, it would simply be an add-on tool. And that's the point.

Can you restate your thesis? Is is that HTTPie should be merged into the cURL project?

> they could have been merged into cURL three years ago (after starting four years ago)

> If this was implemented with libcurl and bundled with cURL

> httpie gains a wealth of advantages

> along with greater support, developer base, test coverage, user base, and lower tco

> and cURL gets syntax highlighting

Re: HTTPie: a CLI, cURL-like tool for humans

#45

Post by dimino »

peterwwillis wrote: post #44
dimino wrote: post #43

Earlier quoted context omitted.

Can you restate your thesis? Is is that HTTPie should be merged into the cURL project?

> they could have been merged into cURL three years ago (after starting four years ago) > If this was implemented with libcurl and bundled with cURL > httpie gains a wealth of advantages > along with greater support, developer base, test coverage, user base, and lower tco > and cURL gets syntax highlighting

Doesn't this assume the maintainers of both projects would be amenable to such a thing, and otherwise be perfectly in unison with regard to vision and goals?

Re: HTTPie: a CLI, cURL-like tool for humans

#46

Post by [deleted] »

jkbr wrote: post #36
alayne wrote: post #23

I've been using HTTPie a lot more recently. It really takes the tedium out of using curl and I can produce color coded output for people. However, I am still finding myself in situations where I can't figure out how to induce the correct request. In other words, the user friendliness of being able to do things like construct JSON from parameters is great until it isn't. Is there anything similar for GUI users? The st…

Do you have an example of a request that you're unable to make with HTTPie?

[deleted]

Re: HTTPie: a CLI, cURL-like tool for humans

#47

Post by peterwwillis »

dimino wrote: post #45
peterwwillis wrote: post #44

Earlier quoted context omitted.

> they could have been merged into cURL three years ago (after starting four years ago) > If this was implemented with libcurl and bundled with cURL > httpie gains a wealth of advantages > along with greater support, developer base, test coverage, user base, and lower tco > and cURL gets syntax highlighting

Doesn't this assume the maintainers of both projects would be amenable to such a thing, and otherwise be perfectly in unison with regard to vision and goals?

Actually, it mainly just assumes the author knows C. If they had they could have simply taken cURL and written some wrapper functions to do the JSON query part and the syntax highlighting, then submitted their modifications. No extra project needed, no grand vision required.

Re: HTTPie: a CLI, cURL-like tool for humans

#48

Post by detaro »

peterwwillis wrote: post #9
scrollaway wrote: post #8

Earlier quoted context omitted.

What do you mean? libcurl is as much a separate project/library as requests is, and this uses requests.

Rephrase: If this was implemented with libcurl and bundled with cURL it would no longer need to exist as a separate project because cURL would develop and support it. Does that make more sense?

What makes you assume that the cURL project wants to support features like syntax highlighting, a second style of command line arguments, ... and would accept such contributions?

Re: HTTPie: a CLI, cURL-like tool for humans

#49

Post by dimino »

peterwwillis wrote: post #47
dimino wrote: post #45

Earlier quoted context omitted.

Doesn't this assume the maintainers of both projects would be amenable to such a thing, and otherwise be perfectly in unison with regard to vision and goals?

Actually, it mainly just assumes the author knows C. If they had they could have simply taken cURL and written some wrapper functions to do the JSON query part and the syntax highlighting, then submitted their modifications. No extra project needed, no grand vision required.

Well no, it assumes what I said, what you said, and a bunch of other things.

Why are you being weirdly insistent that there only exist exactly one tool for making HTTP requests on the command line?

Re: HTTPie: a CLI, cURL-like tool for humans

#50

Post by peterwwillis »

dimino wrote: post #49
peterwwillis wrote: post #47

Earlier quoted context omitted.

Actually, it mainly just assumes the author knows C. If they had they could have simply taken cURL and written some wrapper functions to do the JSON query part and the syntax highlighting, then submitted their modifications. No extra project needed, no grand vision required.

Well no, it assumes what I said, what you said, and a bunch of other things. Why are you being weirdly insistent that there only exist exactly one tool for making HTTP requests on the command line?

> Why are you being weirdly insistent that there only exist exactly one tool for making HTTP requests on the command line?

I'm not. I'm being weirdly insistent that adding features to one good tool is better than having 10 kinda-ok tools all with different features.

Imagine if VLC or MPlayer was actually 10 different video players, all of which supported different media formats and had different features. That was actually somewhat the case for a while; kplayer supported some things, the five different GTK/Gnome players supported some things, they were all relatively buggy and playing video was always annoying. Except for VLC and MPlayer, which just did everything, and were mostly fantastic.

How did VLC and MPlayer do this? They designed their apps specifically so that they could expand in features, and allowed people to contribute new technology. They supported runtime codecs and extensions. And they had a large development and user base, and people saw the benefit in having one tool that supported as many ways possible of doing the one thing they wanted: playing a video.

Having one tool to handle all the weird uses of HTTP may not be reasonable, but having a toolkit that bundles all the weird uses of HTTP would be infinitely more useful than having to download 100 different projects just to munge HTTP requests. There are many such toolkits for other technologies. This is not a new or contentious idea.

Post reply on HN