http - HTTP PATCH リクエストにデータを含める適切な方法

Question

HTTP PATCH リクエストを作成するときに、URL パラメータ以外のデータを含めるにはどのようなオプションがありますか?

次のいずれかが機能しますか?また、最も一般的な選択肢は何ですか?

• マルチパート/フォームデータ
• application/x-www-form-urlencoded
• 生の JSON
• ...他のもの？

Answer 1

RFC 5789PATCHで定義されているように、HTTP 要求のエンティティ ボディに制限はありません。したがって、理論的には、この分野での選択肢は無限です。

私の意見では、唯一の賢明な選択は、Content-Type最初にリソースを作成したのと同じものを使用することです。最も一般的な選択はapplication/json、最新の API のほとんどが優先データ転送形式として JSON を使用するという単純な理由によるものです。

RFC 5789 がPATCHエンティティ本体の一部であるべきものとすべきでないものに関して行う唯一の関連ステートメントは、次の問題について沈黙していますContent-Type。

同封されたエンティティには、オリジンサーバーに現在存在するリソースを変更して新しいバージョンを生成する方法を説明する一連の指示が含まれています。

要約すると、アプリケーション内のリソースをどのように変更するかは、完全にあなた次第です。

Answer 2

rdlowreyが書いているように、RFC 5789は特定のコンテンツ タイプを義務付けていないため、形式の選択はユーザー次第です。

ただし、リストした一般的な形式を使用したり、独自の形式を作成したりすることは相互運用性がなく、開発者は選択したセマンティクスを理解するのに苦労する可能性があります。RFCの公式正誤表は、これをより正式な方法で述べています。

リクエストをリソースの状態に適用する方法はPATCH、リクエストのメディア タイプによって決まります。PATCH 仕様が に固有のセマンティクスを定義していないメディア タイプのリクエストをサーバーが受信した場合、サーバーは、より具体的なエラー ステータス コードが優先されない限り、ステータス コードPATCHを返すことによってリクエストを拒否する必要があります（SHOULD ）。415 Unsupported Media Type

特に、サーバーは、または PATCHなど、定義されていない一般的なメディア タイプのセマンティクスを想定すべきではありません。これを行うと、相互運用性の問題が発生します。これは、 のセマンティクスが一般的ではなく、そのリソースに固有のものになるためです。application/xmlapplication/jsonPATCH

^{(引用は読みやすいように書式設定されていますが、それ以外は変更されていません)}

仕様が PATCH セマンティクスを定義する 1 つのメディア タイプは、 JSON パッチapplication/json-patch+jsonとも呼ばれます: RFC 6902。最初に JSON として投稿されたデータを処理する場合、(少なくとも) 「標準的な」選択と見なすことができると思います。

Answer 3

メソッドはRFC 5789PATCHで定義されています。ただし、このドキュメントでは、ペイロードのメディア タイプは強制されません。

このPATCHメソッドは、リクエスト エンティティで記述された一連の変更を で識別されるリソースに適用するようにリクエストしますRequest-URI。一連の変更は、メディア タイプによって識別される「パッチ ドキュメント」と呼ばれる形式で表されます。

数年後にリリースされた他の RFC では、リソースに適用される一連の変更を記述するためのいくつかのメディア タイプが定義されていますPATCH。

application/json-patch+json

RFC 6902で定義されています。

JSON パッチは、JavaScript Object Notation (JSON) ドキュメントに適用する一連の操作を表現するための JSON ドキュメント構造を定義します。PATCHHTTPメソッドでの使用に適しています。メディア タイプは、そのapplication/json-patch+jsonようなパッチ ドキュメントを識別するために使用されます。

application/merge-patch+json

RFC 7396で次のように定義されています。

この仕様は、JSON マージ パッチの形式と処理規則を定義します。PATCHマージ パッチ形式は、主に、ターゲット リソースのコンテンツに対する一連の変更を記述する手段として、HTTP メソッドで使用することを目的としています。