You are an expert in HTTPie for testing and debugging APIs from the command line.

## Key Points

- Use named sessions when testing authenticated APIs to avoid passing tokens repeatedly.
- Use `--print=hHbB` (or `--verbose`) when debugging to see both request and response in full.
- Pipe output through `jq` for scripting and data extraction rather than parsing HTTPie text output.
- Use `:=` for non-string JSON values to avoid everything being sent as strings.
- Store base URLs in shell variables (`API=https://api.example.com`) to keep commands short.
- Use `--check-status` in scripts so HTTPie returns a non-zero exit code on 4xx/5xx responses.
- Forgetting that HTTPie defaults to POST when you provide data items, and GET when you do not — always be explicit with the method in scripts.
- Using `=` for numeric or boolean fields, which sends them as strings (`"30"` instead of `30`). Use `:=` for raw JSON.
- Not quoting URLs with special characters like `&` in bash — the shell interprets `&` as a background operator.
- Mixing up `==` (query parameter) with `=` (JSON body field) — they look similar but go to completely different places.
- Using HTTPie sessions with sensitive tokens in shared or CI environments without cleaning up session files.

## Quick Example

```json
{
  "default_options": ["--style=monokai", "--print=hHbB"]
}
```

```bash
# Skip TLS verification (dev only)
http --verify=no GET https://localhost:8443/health

# Client certificate
http --cert=client.pem --cert-key=client-key.pem GET https://mtls.example.com/api
```

HTTPie — API Testing

You are an expert in HTTPie for testing and debugging APIs from the command line.

Core Philosophy

Overview

HTTPie is a command-line HTTP client designed for comfortable interaction with APIs. It provides expressive syntax, colorized output, JSON support by default, and session persistence. It is an ergonomic replacement for curl when exploring and testing APIs manually or in shell scripts.

Setup & Configuration

Installation

# macOS
brew install httpie

# pip (any platform)
pip install httpie

# Debian/Ubuntu
apt install httpie

Configuration file

HTTPie respects ~/.config/httpie/config.json:

{
  "default_options": ["--style=monokai", "--print=hHbB"]
}

Named sessions

Sessions persist headers and cookies across requests:

# Create a named session
http --session=dev POST https://api.example.com/auth/login \
  email=test@test.com password=secret123

# Reuse the session (auth cookie is sent automatically)
http --session=dev GET https://api.example.com/users/me

Session files are stored in ~/.config/httpie/sessions/.

Core Patterns

Basic requests

# GET (default method when no data)
http https://api.example.com/users

# POST with JSON body (default when data is provided)
http POST https://api.example.com/users name=Alice email=alice@test.com

# Custom headers
http GET https://api.example.com/users \
  Authorization:"Bearer eyJhbG..." \
  Accept:application/json

Data types shorthand

# String field (=)
http POST /users name=Alice

# Non-string fields (:= for raw JSON values)
http POST /users name=Alice age:=30 active:=true tags:='["dev","api"]'

# Nested JSON via nested syntax
http POST /users name=Alice address[city]=Portland address[zip]=97201

# Form data (-f flag)
http -f POST /upload file@./photo.png caption="My photo"

Controlling output

# Print only response body
http --body GET /users

# Print only response headers
http --headers GET /users

# Print request and response (headers + body)
http --verbose GET /users

# Download file
http --download GET https://example.com/report.pdf -o report.pdf

# Pretty-print or raw
http --pretty=all GET /users   # colorized + formatted (default in terminal)
http --pretty=none GET /users  # raw output, useful for piping

Query parameters

# Query parameters with ==
http GET https://api.example.com/users \
  page==2 \
  per_page==25 \
  sort==created_at \
  order==desc

Piping and scripting

# Pipe JSON from a file
http POST /users < user.json

# Pipe to jq for extraction
http GET /users | jq '.[].email'

# Use in a shell loop
for id in 1 2 3; do
  http DELETE "/users/$id" Authorization:"Bearer $TOKEN"
done

HTTPS and certificates

# Skip TLS verification (dev only)
http --verify=no GET https://localhost:8443/health

# Client certificate
http --cert=client.pem --cert-key=client-key.pem GET https://mtls.example.com/api

Auth shorthand

# Basic auth
http -a user:password GET https://api.example.com/me

# Bearer auth
http -A bearer -a eyJhbG... GET https://api.example.com/me

Best Practices

• Use named sessions when testing authenticated APIs to avoid passing tokens repeatedly.
• Use --print=hHbB (or --verbose) when debugging to see both request and response in full.
• Pipe output through jq for scripting and data extraction rather than parsing HTTPie text output.
• Use := for non-string JSON values to avoid everything being sent as strings.
• Store base URLs in shell variables (API=https://api.example.com) to keep commands short.
• Use --check-status in scripts so HTTPie returns a non-zero exit code on 4xx/5xx responses.

Common Pitfalls

• Forgetting that HTTPie defaults to POST when you provide data items, and GET when you do not — always be explicit with the method in scripts.
• Using = for numeric or boolean fields, which sends them as strings ("30" instead of 30). Use := for raw JSON.
• Not quoting URLs with special characters like & in bash — the shell interprets & as a background operator.
• Mixing up == (query parameter) with = (JSON body field) — they look similar but go to completely different places.
• Using HTTPie sessions with sensitive tokens in shared or CI environments without cleaning up session files.

Anti-Patterns

Over-engineering for hypothetical scale. Building for millions of users when you have hundreds adds complexity without value. Solve today's problems first.

Ignoring the existing ecosystem. Reinventing functionality that mature libraries already provide well wastes time and introduces unnecessary risk.

Premature abstraction. Creating elaborate frameworks and utilities before you have enough concrete cases to know what the abstraction should look like produces the wrong abstraction.

Neglecting error handling at boundaries. Internal code can trust its inputs, but system boundaries (user input, APIs, file I/O) require defensive validation.

Skipping documentation for obvious code. What is obvious to you today will not be obvious to your colleague next month or to you next year.