curl は強いが、書くのは本当に骨が折れる

どの作り手も、手に負えなくなった curl を書いたことがあります。引用符の中に引用符、逃がし記号の上に逃がし記号、一行が画面の半分にわたり、JSON の中の一つの区切りを探すのに何度も試すことになります。HTTPie はまさにその痛みから出発しました。命令行のための現代的な HTTP の道具で、書き方は自然な文に近づくよう設計されています。方法、宛先、鍵と値の組を順に書き、データの欄は name=John の形でそのまま後ろに並べます。JSON は自動で組み立てられ、手で逃がし記号を入れる必要はどこにもありません。

節約できるのは打つ時間だけではありません。一週間後に読み返せる命令は、覚え書きに写せて、作業票に貼れて、同僚に渡せます。そして殻の逃がしの規則こそ、動く命令を記憶から組み直せなくする部分です。それを外すと、一度の試みが残しておけるものに変わります。

読んで気持ちのよい応答

もう一つの長所は返ってくる側です。応答の頭と本文は自動で整えられ、JSON は字下げと桁が揃い、状態の番号と方法は意味に応じて色が付くので、一目で問題の場所を指せます。文字の壁を一字ずつ崩す必要はありません。

3.x の系列では応答にかかった時間の情報が加わり、Pie の趣向と組み合わせると、その時間が緑、黄、橙、赤へと変わるので、遅い窓口が測る道具を開かずに分かります。ほかの部分も揃っています。入室を保って繰り返しの認証を省くこと、一つの命令でのファイルの送信、Bearer と Basic の認証への標準の対応、規約と出力の形式を広げられる追加の仕組み、そして流れる応答が自ら送られていく表示です。

開かれた界隈の古い友人

企画は BSD-3-Clause の許諾で GitHub に公開され、星の数は四万に近く、開発の道具の界隈では長年の定番です。現在の命令行の版は 3.2.4。curl を置き換える気はありません。スクリプトと管の中では curl が王であり、それは当分変わりません。HTTPie が狙うのは人の側で、一つの窓口を試す費用をできるだけゼロに近づけることです。

公式には計算機の画面向けとブラウザー向けの版もあり、端末に慣れていない班の成員も別の道具ではなく同じ道具で調べられるので、結果は班の中で比べられます。

この分担ははっきり書く値があります。こうした道具の論争は、たいてい二つのシーンを混ぜたところから生まれます。人の手を離れて走るものはスクリプトに属し、curl に属します。人が打ち、読み、手直しするものは、命令を読めるままに保つ道具に属し、そこがこの道具の元が取れる場所です。

入室を保つ仕組みは、実際にもっとも時間を節約する部分です。守られた窓口はたいてい、何かを試す前に認証が要ります。二十回目の要求でもそれを手で繰り返していると、人は窓口のことを考える代わりに使い捨てのスクリプトを書き始めます。入室を一か所に保てば、その回り道が消えます。

流れる応答も同じ理由で効きます。出来事を送り続ける窓口は、本文の終わりを待つ道具では見られません。生まれながらに並ぶのを見られることが、遅いサーバーと止まったサーバーを見分ける唯一の手段であることがよくあります。

もう一つ、あまり語られない利点があります。読める命令は、後から振り返ることを可能にします。不具合のときに三日後に自分がどう呼んだかを見返すのは、一から推測し直すよりずっと速いものです。

道具は人に合わせるべきで、人が道具に合わせるべきではない、という考え方です。同じ要求が、curl では呪文になり、ここでは文になります。一度入れておけば、窓口を調べる速さも気分も良くなります。