HTTP：PUTとPATCHの違い
1. 序章
The ハイパーテキスト転送プロトコル （HTTP）は、広く使用されている通信プロトコルです。 このプロトコルは、分散型ハイパーメディア情報システムを実装するために90年代からインターネットで使用されてきました。
そのために、HTTPにはいくつかの標準的な方法があります。 これらのメソッドには、HTTPシステムの開発者が試みなければならない特性と目的があります。 ただし、一部のHTTPメソッドには非常によく似た特性があります。 したがって、HTTPシステムでプログラミングする前に、これらの類似したHTTPメソッドを注意深く分析する必要があります。 たとえば、PUTとPATCHのメソッドには、混乱を招く可能性のある同等の機能があります。 しかし、この記事で見るように、それらは同じではありません。
このチュートリアルでは、PUTとPATCHのHTTPメソッドについて説明します。 まず、HTTPのレビューを行います。 このレビューでは、利用可能なHTTPメソッドとそのプロパティに特に注意を払います。 したがって、PUTメソッドとPATCHメソッドを詳細に調査し、それらについての詳細な説明といくつかの使用例を取得します。 最後に、これらの方法を体系的な要約で比較します。
2. HTTPの概要
HTTPは、クライアントとサーバーが通信してデータを交換できるようにするアプリケーション層プロトコルです。 運用上、HTTPはネットワーク層でインターネットプロトコル（IP）を介して機能し、トランスポート層で伝送制御プロトコル（TCP）を介して機能します。 さらに、要求/応答モデルを採用しています。 したがって、クライアントは要求を送信し、サーバーの応答を待ちます。
つまり、HTTPリクエストには、URI（Uniform Resource Identifier）と目的のメソッドが含まれています。 さらに、必要に応じて、リクエスト修飾子と本文のコンテンツを含めることができます。 次に、サーバーの応答には、成功またはエラーコードと、エンティティと呼ばれるペイロードが含まれます。
2.1. HTTPメソッドの概要
HTTPのリクエストメソッドは、特定のリソースに対して実行されたアクションを示します。 9つのメソッドがあります。そのうちの8つはHTTP1.1のベースドキュメント（ RFC 7231 ）のコンテキストで指定され、もう1つ（PATCH）は特定のドキュメント（ RFC 5789 ）で指定されます。 ）：：
- オプション：サポートされているリソースのHTTPメソッドについて説明します。 さらに、これらのリソースのオプション、要件、およびパラメーターを通知します
- 得る：リソースに関する情報を受信するために使用されます。 このように、このメソッドは、すでに利用可能なデータを返すか、サーバーでデータ生成プロセスをトリガーすることができます
- 頭：GETメソッドのHTTPヘッダーのメタ情報のみを返します。 エンティティの本文コンテンツが提供されていないことを意味します
- 役職：リクエスト内でリソースの新しいエンティティを送信するように設計されています。 したがって、サーバーは受信したエンティティをリソースに従属させます
- PUT ：リソースの囲まれたエンティティをサーバーに送信します。 エンティティがすでに存在する場合、サーバーはそのデータを更新します。 それ以外の場合、サーバーは新しいエンティティを作成します
- DELETE ：リソースのエンティティの削除をトリガーします。 リクエストはターゲットエンティティに通知する必要があります
- 痕跡：デバッグ目的のメソッド。 リクエスト全体をクライアントに返します。 通常、ゲートウェイとプロキシのテストではこの方法を使用します
- 接続：トンネリング通信に使用されます。 たとえば、SSL対応のWebサイトとの接続を確立すると便利です
- PATCH ：リソースのエンティティの変更を許可します。 したがって、エンティティデータの特定の部分のみを変更するために適用できます
2.2. HTTPメソッドのプロパティ
HTTPメソッドには、安全性とべき等性という2つの関連するプロパティがあります。
- 安全性：メソッドは、要求されたときに情報の取得よりもアクションを実行することを意図していない場合は安全です。 安全性は、サーバーに副作用がないことと見なすことができます。 メソッドの処理。 ただし、とにかく副作用が発生した場合、それは単なる結果であり、ユーザーの要求ではありません。 慣例により、OPTIONS、HEAD、およびGETは安全なメソッドです
- べき等：このプロパティは、同じリクエストを複数回処理した場合のサーバーへの副作用は、リクエストを1回処理した場合と同等であることを意味します。 したがって、GET、HEAD、PUT、DELETE、OPTIONS、およびTRACEはべき等のメソッドです。
3. PUTメソッド
クライアントは、PUTメソッドを使用して、リソースのエンティティをHTTPサーバーにセットアップします。 このセットアッププロセスは、次の2つの形式で実行できます。
- エンティティが存在せず、サーバーは要求されたリソースの新しいエンティティを作成し、成功コード201でクライアントに応答します
- エンティティはすでに存在します。 サーバーはエンティティを更新し、成功コード200または204でクライアントに応答します。 さらに、PUT要求の処理中にエラーが発生した場合、サーバーは適切なエラーコード（通常は4xxまたは5xx）でクライアントに応答する必要があります。
預金箱の貸し手を登録する簡単な例を考えてみましょう。 したがって、エージェントは貸手に関する情報を収集し、特定の預金ボックスの最初の登録をPOSTします。
しばらくすると、デポジットボックスは別の貸し手に移されます。 したがって、エージェントは新しい貸し手の情報を収集し、PUTメソッドを介してデポジットボックスのすべてのデータを更新します。
PUTメソッドは、リクエストで提供された正確な情報を使用してエンティティを設定することに注意してください。 このように、リクエストには特定のフィールドだけでなく、エンティティ全体が含まれている必要があります。 ただし、保証金ボックスが新しい貸し手に譲渡されると、すべての個人情報（または少なくともそのほとんど）が変更されることが予想されます。 したがって、PUTはこのシナリオにうまく適合します。
4. パッチ方式
PATCHメソッドは、リソースのエンティティに部分的な変更を適用します。 PATCHメソッドは、要求された変更をアトミックに実行します。 これは、サーバーが要求されたすべての変更を満たせない場合、ターゲットエンティティを変更しないことを意味します。 このようにして、要求が正常に実行されると、サーバーは成功コード204をクライアントに返します。 それ以外の場合、サーバーはエラーコードを返します。
PATCHメソッドの採用の具体的なシナリオを確認するために、前のセクションで示した例の新しいケースを考えてみましょう。 しばらくすると、デポジットボックスの新しい貸し手が自分の電子メールアドレスを変更します。 そこで、彼女は新しい電子メールアドレスをデポジットボックスエージェントに通知します。 次に、エージェントはPATCHメソッドを介して貸手レジスタの更新を実行します。
PUTメソッドとは異なり、PATCHメソッドでは、エンティティの特定のフィールドのデータを更新できます。 この例では、デポジットボックスの貸し手は電子メール情報のみを変更し、残りのレジスターは同じデータのままにしました。 したがって、PATCHメソッドは、この特定の更新を処理するのに適しています。
5. PUT vs. パッチ
シナリオによっては、PUTまたはPATCHの使用を決定するのが難しい場合があります。
ただし、要求されたメソッドを変更するだけで異なる結果が得られるシナリオが存在します。 たとえば、4番目のセクションのシナリオでPATCHの代わりにPUTメソッドを要求すると、情報が失われます。 この場合、PUTメソッドは、電子メールデータを除くすべてをエンティティから削除します。 したがって、この特定の要求ケースの目的を満たすには、PATCHメソッドのみが適切です。
PUTまたはPATCH法を採用する意思決定では、それらの特定の特性を考慮する必要があります。 したがって、次の表は、このプロセスに役立つこれらの特性の一部を示しています。
6. 結論
この記事では、PUTとPATCHのHTTPメソッドについて学びました。 最初に、HTTPプロトコルの簡単なレビューを行いました。 次に、理論的な説明と実際の例を通じて、PUTとPATCHの方法を詳細に分析しました。 最後に、PUTとPATCHの両方を比較して、それぞれがより適しているシナリオの概要を示しました。
PUTとPATCHの方法には多くの類似点があると結論付けることができます。 ただし、HTTPサーバーを実装して要求するときに考慮する必要がある、特定の特性があります。
