HTTPie — API Testing Platform
Evaluated and rejected. curl+jq composes with everything. HTTPie composes with nothing.
Category |
IDEAS |
Status |
Rejected |
Source |
|
Evaluated |
2026-04-07 |
Premise
HTTPie (httpie.io) offers a CLI (http) and desktop app for API interaction with automatic JSON formatting, syntax highlighting, and simpler syntax than curl. The question: does it earn a place in a terminal-first workflow built on curl+jq+awk pipeline composition?
Decision
Rejected. The justification follows the Aristotelian framework.
Logos — The Logical Argument
HTTPie is a closed system. It formats output for human eyes but does not compose with other tools. curl+jq is an open system — it connects to any tool in the Unix pipeline.
What curl+jq can do that HTTPie cannot:
# Filter and reshape — jq is a full programming language
curl -s localhost:8080/standards | jq '[.standards[] | select(.status != "Active") | {id, status}]'
# Aggregate across endpoints — pipe into awk
curl -s localhost:8080/search?q=802.1X | jq -r '.results[] | "\(.component)\t\(.title)"' | \
awk -F'\t' '{c[$1]++} END {for (k in c) printf "%s: %d hits\n", k, c[k]}'
# Diff two API responses — process substitution
diff <(curl -s localhost:8080/standards | jq -r '.standards[].id' | sort) \
<(curl -s localhost:8080/pages?category=standards | jq -r '.pages[].path' | awk -F/ '{print $NF}' | sort)
# Batch operations — xargs parallelism
curl -s localhost:8080/codex | jq -r '.categories | keys[]' | \
xargs -P4 -I{} sh -c 'curl -s "localhost:8080/codex/{}" | jq -r "\"{}: \" + (.count | tostring)"'
# Status code inspection — curl's -w flag
curl -s -o /dev/null -w '%{http_code}' localhost:8080/standards
HTTPie’s equivalent: http localhost:8080/standards. Pretty output. No transformation. No composition. No pipeline.
curl speaks 25+ protocols (HTTP, FTP, SMTP, WebSocket). HTTPie speaks HTTP only. curl’s -w flag exposes timing, headers, status codes as template variables. HTTPie has no equivalent.
Ethos — The Credibility Argument
The engineers who build and operate production systems use curl. Every server has it. Every CI pipeline uses it. Every runbook references it. Every vendor’s API documentation shows curl examples — not HTTPie.
Building fluency in curl+jq makes you immediately productive on any system, any team, any infrastructure. HTTPie fluency transfers nowhere. When you SSH into a production box at 2 AM during an incident, curl is there. HTTPie is not.
The domus-api validate.sh script, the demo.sh walkthrough, the API CLI Mastery curriculum — all built on curl+jq. This is not accidental. It is the tool that scales from learning to production.
Pathos — The Visceral Argument
HTTPie makes the terminal feel like a GUI. Colors, formatting, friendly syntax — it optimizes for comfort. curl+jq optimizes for power. The discomfort of learning jq '.standards[] | select(.status != "Active")' is the price of being able to think in pipelines.
Every time you reach for the harder tool, you close a gap between yourself and the engineers who build the systems you want to build. HTTPie closes no gaps. It makes the easy thing easier. The easy thing was never the bottleneck.
What HTTPie Does Well
For completeness: HTTPie CLI provides automatic JSON syntax highlighting without piping to jq. For a quick http localhost:8080/stats visual check, it is genuinely faster than curl -s | jq. If the workflow were "look at API responses and do nothing with them," HTTPie would win.
That is not the workflow.
Notes
Captured as an idea on 2026-04-07. Evaluated same day against the curl+jq+awk pipeline approach that domus-api and its curriculum are built on. Rejected on all three axes of the Aristotelian framework.