🐿️ 🚆 ❇️ HTTPプロトコルで適切に動作することに関する15の些細な事実 🕡 ⏰ ♨️

注意！ 広告！ Captain Obviousが投稿した投稿！

以下では、HTTPプロトコルを介して利用可能なリソースの適切な編成を説明する15のポイントを見つけます-Webサイト、バックエンド「ペン」、APIなど。ここでの「正しい」とは、「推奨事項と仕様に準拠すること」を意味します。以下のほとんどは、IETFおよびW3Cの公式の標準、ガイドライン、およびベストプラクティスからほぼ文字通り翻訳されています。

ここでは明白なことは絶対にありません。いいえ、真剣に、 すべての Web開発者は、理論的には、ジュニア開発者および/または大学の2年または3年の領域のどこかでこれらの15点をマスターする必要があります。

しかし、実際には、非常に多くのWeb開発者がこれらの基本を学ばなかったことがわかりました。他のAPIとおしゃべりのドキュメントを読みます。すべての読者がこのリストで自分にとって新しいものを見つけると確信しています。

1. URLはリソース（特定の共有エンティティ）を識別します。ファイルはリソースです。何かを探しているペンはリソースです。メソッド呼び出しはリソースではありません。月の大砲を避けたい場合は、これを行う必要はありません。

GET /?method=&to=

リソース「sharakhalka」を取得すると、すべてが論理的になります。

 POST //?to=

GETではなくPOSTを使用する理由以下をお読みください。

2. URLは、スキーム（プロトコル）、ホスト、パス（パス）、クエリ（クエリ）、およびフラグメントで構成されます。パスは階層リソースの整理に使用され、クエリは非階層リソースおよび操作パラメーターに使用されます。フラグメントは、直接URLを持たない従属リソースを識別します。

スキームホストパスクエリフラグメント
   ↓↓↓↓↓↓
 http://nyashnye-kotiki.xxx/breeds/maine-coon/?deliver_to=Moscow#photo

サイト「Cute cats」に品種のカタログがある場合、各猫は正確に1つの品種に属するため、パスパーツの形式で整理することは非常に論理的です。ただし、1匹の猫を複数の都市に配信できるため、「都市Nへの配信を使用する」フィルターはクエリを使用して整理する必要があります。

3. HTTP呼び出しは、メソッド（動詞）をURLに適用することで構成されます。このアプリケーションの結果-驚き、驚き！ -動詞に書かれていること。つまり、GETはリソースの表現、DELETE削除などを返します。

4.メソッドGET、HEAD、OPTIONSは安全です。これらのメソッドを呼び出してもリソースの状態は変わらないと想定されています。したがって、多くのネットワークエージェント（たとえば、ブラウザまたはメッセンジャーのリンクプリフェッチャーなど）は、ユーザーの明示的な意思なしにそのようなリンクをたどる資格があると考えています。 ICHSH、標準に違反しないでください。

5.デフォルトでは、GETメソッドとHEADメソッドはキャッシュされますが、OPTIONS、POST、PUT、PATCH、DELETEはキャッシュされません。したがって、POSTメソッドを使用して月にジャンプした場合、このリクエストが実行されることは（ほぼ）確実です。 GETメソッドを使用してシャッフルすると、いくつかの中間プロキシがキャッシュから回答を突然提供し、ボールは実際には発生しません。

6. GET、PUT、DELETE操作は対称的です。 PUTはURLに何かを置き（新しいリソースを作成するか、古いリソースを上書きします）、このURLに対するGETはPUTを置いたものの表現を返し、DELETEはリソースを削除します。

HEADメソッドは、GETメソッドと意味的に同義ですが、応答の本文ではなく、ヘッダー（リソースに関するメタ情報）のみを返します。

7.操作を適用するURLがない場合は、POSTが使用されます。たとえば、ユーザーがフォーラムのスレッドに新しいメッセージを書き込む場合、ユーザーは自分のIDを把握して次の操作を実行できます。

 PUT /threads/php-rulezz/messages/100500

クライアントがIDの生成を許可されていない場合、クライアントは階層の上位レベルのリソースでPOSTを実行する必要があります。

 POST /threads/php-rulezz/messages

そして、このリソース自体が新しいメッセージを作成します。

誤って、またはネットワークの問題によりPOSTリクエストを繰り返した場合、最初のメッセージと同じ2番目のメッセージがスレッドに作成されることに注意してください。少なくとも100500回PUTを実行できますが、結果は変わりません。このプロパティは、べき等性と呼ばれます。

さて、フォーラムの投稿を作成します。現在、ユーザー要求に対して重い操作と高価な操作を実行している場合、これに対してべき等の要求を実行することを強くお勧めします。そして、それは写真のようになります：

もちろん、べき等PUTの使用にはそれ自体の問題があります。特に、競合の解決方法です。もっとプログラミングする必要がありますが、結果はより信頼性が高く安全です。

8. PUTは、新しいリソースの作成と古いリソースの更新の両方に使用できます。ただし、PUTを書き換えに使用する場合、エンコードされたリソース全体が要求本文で送信されると想定されます。リソースを変更する場合、つまり完全に書き直さずに内部表現を変更するために、PATCHメソッドが発明されました。このメソッドは、キャッシュ不可で、安全ではなく、べき等ではありません。

9.クライアントが次に何をすべきかを理解できるように、最初に応答コードが必要です。 3xxは、リクエストを正常に完了するには、追加のアクションを実行する必要があると述べています。 4xxは、クライアントがリクエストをコンパイルするときに何か間違ったことをし、通常、頼むことは役に立たないので、リクエストを繰り返し実行するとエラーがスローされると言います。 4xxでは、クライアントが正確に何を間違えたかについての情報を含めることを強くお勧めします。 5xxは、クライアントがすべてを正しく行ったと言います-問題はサーバー側にあります。

通常、操作が成功すると、サーバーはGET-200、PUT-201 Created（リソースが作成された場合）または200（リソースが更新された）、DELETE-204（操作が成功し、何も返されない）、POST-200または201（2番目）に応答しますヘッダー（通常は場所）の場合、作成されたリソースのURLが示されます）。

10. HTTPステータスを使用する場合、一般的なレーキを踏まないでください。

401 Unauthorizedステータスには WWW-Authenticateヘッダーが必要であるため、クライアントがHTTP認証で認証された場合にのみ適用されます。その他の場合はすべて、403 Forbiddenを使用します。
3xxステータスはリダイレクトだけではありません。それらは、クライアントが追加のアクションを実行する必要があることを示しています。そうしないと、リクエストが成功したと見なすことができません。たとえば、ステータス304 Not Modifiedの場合、クライアントはキャッシュからリソースの現在のバージョンを取得する必要があります。
奇妙なことに、404ステータスは、クライアントが繰り返す権利を持つ数少ない4xxステータスの1つです。これは、現在リソースがないことを意味しますが、表示される可能性は十分にあります。一般に、404は、サーバーがエラーのメカニズムを開示したくない場合に使用される不確実性ステータスです。クライアントが追加のアクションを行わないとリソースが表示されないことをクライアントに示すには、410 Gone（リソースが削除された）または一般ステータス400を使用する必要があります。

11.リソースとそのアクションをエンコードするURLの特別なサブクラスがあります。英語の文献では、それらは機能URLと呼ばれます。このようなURLの典型的な例は、パスワード回復リンクと、あらゆる種類のリソースへのあらゆる種類の「秘密」直接リンクです。

12.ケーパビリティURLを扱う際の主な危険は漏洩の可能性であるため、そのようなURLを誤って発見または傍受する可能性を閉じる必要があります。

URLの秘密の部分を生成するには、強力なランダム文字列ジェネレーター（ UUID 4など）を使用する必要があります。ただし、ブルートフォースによって機能URLを見つける可能性はありません。もちろん、md5（ユーザー名）のような決定論的な方法でURLを生成するべきではなく、そのようなURLはリンク短縮サービスを介して渡すべきではありません。
機能URLはHTTPSでのみ機能します。
機能URLを介してアクセス可能なページは、ロボットによるインデックス作成をワイルドカードでブロックする必要があります。

13.起こりうる損傷を最小限に抑えるための対策を講じる必要があります。

機能URLを作成した（たとえば、ドキュメントを共有した）ユーザーは、逆の操作を実行できる必要があります。 URLを取り消す

機能URLは時間の経過とともに悪化するはずです。アクセスが危険であるほど、URLの寿命は短くなります。

14.最後に、「シークレット」ページ自体を、サードパーティエージェントへのデータ漏洩から保護する必要があります。

できればCSPレベルで、サードパーティのスクリプトや画像を使用しないでください。
サードパーティのサイトへのリンクを使用しないでください。必要な場合は、たとえばrel = "noreferrer"を使用してリファラーを非表示にする必要があります。
通常、リファラーポリシーを介してリファラーの非表示を設定することをお勧めします。
ユーザーがあなたの肩越しに覗かないように、ユーザーがHistory APIを介してログインした直後に、ブラウザーのアドレスバーのURLをすぐに変更することをお勧めします
リンクに何らかのアクション（パスワードの変更など）が含まれる場合、シークレットページにアクションを実行するために送信する必要のあるフォーム（ボタン、スクリプト）があり、このフォームはCSRFトークン（ブラウザまたは電子メールプリフェッチャー）で署名する必要がありますクライアント/メッセンジャーはユーザーのパスワードを回復できます）。

15.上記のすべては、推奨事項の形式でのみ標準に存在し、これらの推奨事項を厳密に実装するように強制することは不可能です。このトリビアについて私が話しているのはこれが初めてではなく、「はい、これをすべて吐き出したかったのです。彼らは不必要なナンセンスを思いつきました。すべてのサービスがGETでのみ私のために働いたように、それらは引き続きそうであり、あなた自身のPUTとDELETEに苦しむでしょう。

もちろん、自分でサービスを自由に書くことができます。ただし、サーバーとクライアントの間には、同じDC内で物理的に隣り合っていても、ブラウザ、プロキシ、ルーター、異なるプログラミング言語および異なるOSでのHTTPプロトコル実装など、膨大な数のネットワークエージェントが存在することに注意してください、DPI機器プロバイダーなど。これらのプラスまたはマイナスのエージェントはすべて、RFCに注目してHTTPプロトコルを実装しています。

突然クライアントのブラウザーが月のGETリンクとフラウンダーを拒否した場合-それはあなたのせいになります。メーカーに連絡するのは無意味です。 GETリクエストを使用してお金を転送し、プログラミング言語でHTTPプロトコルを実装すると、近隣のルーターからの応答を待たずに、リクエストを繰り返し、トランザクションを2回実行することになります。

しかし、これは主要なことすらありません。 HTTPパケットが厳密に制御された環境を歩いているとしましょう。違反した推奨事項とその理由を他の開発者にどのように説明しますか？このGETリクエストを繰り返すことはできず、ステータス400はクライアントエラーを意味しないことを同僚はどのように理解する必要がありますか？推奨事項とは異なり、実際には、独自のセマンティクスを使用して、何らかの独自のHTTP方言を作成するたびに作成します。少なくとも文書化することを忘れないでください;）

参照：

（あなたの謙虚な使用人は、最後の文書の開発に一定の役割を果たしました。）

HTTPプロトコルで適切に動作することに関する15の些細な事実

More articles: