curl 很強，但寫起來真累

每個開發者都寫過那種失控的 curl：引號套引號、跳脫疊跳脫，一行指令橫跨半個螢幕，JSON 請求主體裡找一個逗號都要試上幾次。HTTPie 的起點正是這個痛點。它是面向命令列的現代 HTTP 用戶端，語法設計得接近自然語言：請求方法、位址、鍵值對照順序寫下來，資料欄位用 name=John 的形式直接跟在後面，JSON 自動序列化，完全不需要手動跳脫。

省下的不只是打字時間。一週之後還讀得回來的指令，才複製得進筆記、貼得進工單、交得到同事手上；而 shell 的跳脫規則，恰恰是讓一條能跑的指令無法憑記憶重建的那一部分。把它拿掉，一次實驗就變成一份可以留下來的東西。

讀起來舒服的回應輸出

另一個長處是回傳的東西。回應標頭與主體自動格式化，JSON 縮排對齊，狀態碼與請求方法按語意著色，掃一眼就能定位問題，不必在一整片文字裡逐字拆解。

3.x 版本加入了回應耗時的中繼資料，搭配 Pie 主題，耗時會依綠、黃、橙、紅變色，哪個端點慢，不必開分析工具就看得出來。其餘的也都在：工作階段讓登入不必重複、上傳檔案只要一條指令、原生支援 Bearer 與 Basic 認證、外掛體系可以擴充協定與輸出格式，串流回應也能自動捲動顯示。

開源社群的老朋友

專案以 BSD-3-Clause 授權開源在 GitHub，星標數接近四萬，是開發者工具圈裡多年的固定班底，目前命令列版本 3.2.4。它並不是要取代 curl。在腳本與管線裡，curl 依然稱王，這點短期不會改變。HTTPie 針對的是人的那一側：把「測一個介面」的成本壓到最低。

官方另外提供桌面版與網頁版，團隊裡不熟終端機的成員可以用同一套工具除錯，而不是另一套，結果在團隊內部也就還能對得上。

這個分工值得講清楚，因為關於這類工具的爭論，通常來自把兩種情境混在一起。凡是得無人看管地跑起來的，屬於腳本，屬於 curl；凡是人親手打字、親眼讀、隨手改的，屬於讓指令保持可讀的那一個，而它正是在這裡回本。

工作階段是實務上最省時間的一項。受保護的端點通常要先登入才能測，測到第二十個請求還在手動重複登入，人就會開始寫一次性的腳本，而不是繼續想介面本身。把工作階段留在一處，這條繞路就消失了。

串流回應也是同樣的道理。持續送出事件的端點，沒辦法用一個「等主體結束」的工具來看。邊產生邊顯示，往往是分辨「伺服器慢」與「已經卡住」的唯一辦法。

還有一點很少被提起：可讀的指令讓複盤變成可能。出問題時回頭看自己三天前是怎麼呼叫的，比重新推測一次快得多。

它的哲學是「工具應該遷就人，而不是人遷就工具」：同一個請求，curl 寫出來是咒語，這裡寫出來是句子。裝一次，您會發現自己除錯介面的速度與心情都變好了。