Webクライアント

先に尋ねるほうがクライアントです

クライアントとサーバーは機械ではなく役割です。先に話しかけて何かを求めるほうがクライアント、待って答えるほうがサーバーです。ブラウザーもクライアント、curlもクライアント、スマホアプリも、APIを呼ぶ別のサーバーもクライアントです。

だからWebクライアントは一行で書けます。窓も、描画エンジンも、マウスも要りません — つなぎ、リクエストを送り、返ってきたものを読めばよいのです。

ターミナルでWebクライアントを作る

HTTPが文字にすぎないといちばん早く納得する方法は、リクエストを自分で打つことです。前のテーマのシェルWebサーバーを立てておき、ターミナルをもう一つ開いて手で話しかけてみてください。

ncでリクエストを手書きする

netcatはポートにつなぎ、打った文字をそのまま線へ流します。二行打ってEnterを二度押せばサーバーが答えます — 今あなたはブラウザーの仕事を手でやりました。

# connect, then type the two lines below and press Enter once more
nc localhost 8084

GET / HTTP/1.1
Host: localhost

# or send it all at once (printf's \r\n is HTTP's line break)
printf 'GET / HTTP/1.1\r\nHost: localhost\r\n\r\n' | nc localhost 8084

• 最後の空行が大事です。リクエストが終わったとサーバーに告げる印で、だからEnterをもう一度押します。
• HTTPは行末ごとにキャリッジリターンと改行を求めます。手打ちでも通るのは多くのサーバーが寛容だからで、printf版は規格が求めるとおりを送ります。
• Hostの行はHTTP/1.1が必ず求めます。本物のサイトへこれなしで送ると、ページではなくエラーが返るのがふつうです。

スクリプトに包む

リクエストがprintf一行になれば、使い回せるクライアントは数行で済みます。下のスクリプトはホスト・ポート・パスを受け取ってリクエストを送り、ヘッダーと本文を分けて見せます。

#!/bin/bash
# usage: bash client.sh localhost 8084 /

HOST=${1:-localhost}
PORT=${2:-8084}
PATH_=${3:-/}

printf 'GET %s HTTP/1.1\r\nHost: %s\r\nConnection: close\r\n\r\n' "$PATH_" "$HOST" \
  | nc "$HOST" "$PORT" \
  | tr -d '\r' \
  | awk 'BODY { print; next } /^$/ { BODY = 1; next } { print "[header] " $0 }'

trはHTTPが行末ごとに残すキャリッジリターンを取り除き、awkは空行に出会うまでをヘッダーとして印を付けます — その後はすべて本文です。ブラウザーが描き始める前にする分け方とまったく同じです。

curl — 毎日使うことになるクライアント

こちらのスクリプトが大ざっぱにやっていたことを、curlはきちんとやります。リダイレクト、HTTPS、ヘッダー、アップロード、時間切れ、クッキーまで。ほとんどの機械に入っていて、ブラウザーを挟まずにサーバーを確かめる標準の手段です。

# body only
curl http://localhost:8084

# body plus the response headers
curl -i http://localhost:8084

# the whole exchange, request headers included
curl -v http://localhost:8084

大事なオプション

APIを呼ぶ

今どきのアプリが話す相手は、ページではなくJSONを返すAPIであることが多いものです。curlがそれを取り、jqが読みやすく整えます。アプリのコードを一行も書かないうちにエンドポイントを確かめる方法です。

# fetch JSON and pick one field out of it with jq
curl -s https://api.github.com/repos/sveltejs/svelte | jq '.stargazers_count'

# send JSON with POST
curl -X POST https://httpbin.org/post \
  -H 'Content-Type: application/json' \
  -d '{"name":"PES","level":1}'

# download to a file
curl -L -o page.html https://getpes.com

何であれまずcurlで試す癖を付けてください。curlが正しい答えを受け取ればサーバーは無事で、間違いは自分のプログラムにあります。curlも変な答えを受け取るなら、見当違いの場所を半日探す手間を省いたことになります。

Chromeも同じクライアント、大きさが違うだけ

Chromeは、あなたがncで送ったそのリクエストを送ります。そのあと、返ってきた答えを人が見られる画面に変える途方もない仕事を足します — 本当の違いはその「足し」だけです。

その段取りを知っておく価値があります。一つひとつがページの狂う場所だからです。何かが出てこないとき問うべきは、いつでも「どの段階で失敗したのか」です。

アドレス欄から絵まで

1. 名前を解く DNSがドメイン名をIPアドレスに変えます。ここで失敗するとサーバーに届きもせず、エラーもページではなく名前を指します。
2. つないで安全にする 接続を開き、httpsなら何かを送る前に証明書を確かめます。ここで出る警告はページがないという意味ではなく、暗号を信用できないという意味です。
3. リクエストを送る あなたが手で打ったのと同じ数行に、ヘッダーがずっと多く付きます。クッキー、読める形式、好みの言語などです。
4. 解釈して残りを取りに行く HTMLを読み、タグから要素の木を組み立て、ページが指すものをすべて要求します — スタイルシート、画像、フォント、スクリプトを、たいてい同時に何本も。
5. 飾り、並べ、描く CSSを当て、箱ごとの位置を計算し、結果を描き、そのすべてをまた書き換えられるJavaScriptを走らせます。

ターミナルのクライアントか、ブラウザーか

開発者ツール — 行き交う文章を目で見る

Chromeには世界でいちばん優れたWebのデバッグ道具が入っていて、もう入っています。ncで手ずから送っていたものが、ここではリクエスト一件ずつ、隣にレスポンスも添えて並びます。

パネル

いますぐ試す三つ

1. 自分のリクエストを探す Networkパネルを開いてこのページを再読み込みし、いちばん最初の項目を押してください。そこにあるリクエストとレスポンスのヘッダーが、ncに打ち込んでいたあの行そのものです。
2. curlとしてコピーする リクエストを右クリックして[Copy as cURL]を選び、ターミナルに貼り付けてください。ヘッダーもクッキーもそのまま、ブラウザーがした通りを再現したことになります。
3. わざと壊してみる Elementsパネルで見出しを消して消えるのを見て、Networkで速度を遅く絞ってから再読み込みしてみてください。どちらも安全で、どちらも読むより多くを教えてくれます。