みなさんはRFC読んでますか...🤔
自分は普段、ガッツリと読む機会はないのですが、新しいプロトコルを触るような場合に読んだことがある程度です。
過去にWebSocketを使ってSlackライクなチャットアプリを作ったことがあるのですが、その際にWebSocketのRFCを読んだことを覚えています。
しかし、WEB開発において最も使用しているであろうHTTPプロトコルのRFCを読んだことはありませんでした。
直近でいくらかAPIを設計する予定があって「良い機会だな...」と思うので、HTTPのRFCを読んでみようと思います。
といっても、文量が多いため、まずはステータスに関する項目(Status Code Definitions)のみに絞りました。どのステータスがどのようなケースを想定して用意されているものなのか興味があります。
内容を理解できるかは自信がありませんが、RFCにはどのようなことが書かれていたのかを紹介していきます。
HTTPのRFCは廃止されてる？
有志の方が日本語に翻訳したものを公開しているので、そちらを読みました。
ファイル上部に「このRFCは廃止されました」とありますが、内容全てが廃止されているのではないようです。
項目の一部に変更がある場合、別のRFCとして変更内容がまとめられて、更新後のRFCとして公開されています。なのでHTTPのRFC2616はマスターファイルのような役割をしており、変更がツリーのように別のRFCとして公開されています。最新情報をまとめるのは骨が折れそうです...。
RFC Editorというサイトで検索すると後続のRFCがいくつもある事が分かります。
例えば、RFC6586ではステータスの追加がされています。
- 428 Precondition Required
- 429 Too Many Requests
- 431 Request Header Fields Too Large
- 511 Network Authentication Required
どれも馴染みのあるステータスではないですね。
RFC2616 Status Code Definitionsを読んでみる
全て紹介するのは難しいので、面白いな...と感じた内容を抜粋して紹介します。
読んでいて全体的に感じたことなのですが、単語が何を指しているのかを理解することが非常に重要です。
例えばエンティティ(Entity)という単語が頻出しますが、エンティティが何を指しているのかが分からないと、内容が全く頭に入ってきません。
今回はStatus Code Definitionsから読むというイレギュラーな方法ですが、エンティティ(Entity)の説明は同RFC内でされているため「この単語なんだろう？」と思ったものがあれば、RFC内を探せば見つかることが多いです。
またRFCには、API設計時などに適切なステータスを選択するための参考情報が記載されているのかと思っていますが、必ずしもそうとは言えませんでした。抽象的な内容もあるため、判断が難しいものもあります。
どちらかというとMozillaが公開しているリクエストメソッドに関するドキュメントが役立つと感じました。
101 Switching Protocols
RFC2616では100系のステータスは100 Continueと101 Switching Protocolsの2つが定義されています。
そもそも100系のステータスを使う機会が全くないのですが、一度、WebSocketのRFCを読んだ際に見覚えがあります。
WebSocketではハンドシェイクを行う際にHTTPでリクエストを行い、サーバーは101 Switching Protocolsを返します。その後、スターテスを受け取ったクライントはプロトコルをWebSocketに切り替えます。
Response
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Writing WebSocket servers - Web APIs | MDN
203 Non-Authoritative Information
このステータスを直訳すると「信頼できない情報」になります。
いや、信頼できない情報って何だよ...。一体、どこで使うべきステータスなのでしょうか。
内容を見て理解するに、元のサーバー以外から取得された情報、例えばキャッシュされた情報が返された時に使用を検討するステータスのようです。
The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy
エンティティヘッダーで返されるメタ情報は、オリジンサーバーから入手できる決定的なセットではなく、ローカルまたはサードパーティのコピーから収集されます。
自分だったら普通に200ステータスを返してしまいそうです。
204 No Content
PATCHやDELETEメソッドでリクエストを受けた際に返すことが多いステータスです。
APIによってはレスポンスボディがあったり、なかったり...。RFCでは、その是非について記載がありました。
The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
204応答にはメッセージ本文を含めてはならないため、常にヘッダーフィールドの後の最初の空行で終了します。
MUST NOTとあるように、かなり強いメッセージを感じます。
今まで204を返しているのにレスポンスボディを返していたことがあったので、猛烈に反省しました...。
402 Payment Required
This code is reserved for future use.
このコードは将来の使用のために予約されています。
RFC2616が公開された当時、まだインターネット上で商品を買うことは一般的ではなかったでしょう。
当時、将来のために「402 支払いが必要」というスターテスを定めた感性には脱帽です。例えば、有料会員限定のコンテンツに制限をかけたい場合に、402ステータスを返すという設計は十分に有効そうです。
しかしながら、なんと2023年の現在でもこのステータスは予約済みのままです。
いつになったら使えるようになるのか楽しみですね。
402 Payment Required - HTTP | MDN
最後に
RFC2616のStatus Code Definitionsの面白いと感じたものを抜粋して紹介しました。
なかなかRFCを読む機会がなかったので、こうやって改めて見てみると発見があって面白いです。
特にHTTPはWEB開発に携わっているエンジニアであれば、知識があって困る事はないでしょう。少し文量は多いですが、RFC2616をもう少し読み込んでみたいと思います。
みなさんのRFCを読むきっかけになれば嬉しいです。
少しでも「ええな〜」と思ったらはてなスター・はてなブックマーク・シェアを頂けると励みになります。
