PATCHメソッド(パッチメソッド)とは | 意味や読み方など丁寧でわかりやすい用語解説

PATCHメソッドは、Webアプリケーション開発で頻繁に利用されるHTTPメソッドの一つである。これは、既存のWebリソースに対して「部分的な更新」を行うために設計されている。一般的なHTTPメソッドとして、リソース全体を新規作成するPOSTや、リソース全体を置き換えるPUTなどがあるが、PATCHメソッドはこれらとは異なり、リソースの特定の属性や一部のみを変更したい場合に利用される。たとえば、ユーザー情報のプロフィールを更新する際に、名前だけを変更したい、あるいはメールアドレスだけを変更したいといった状況で、リソース全体を再送信することなく、変更したい差分情報のみをサーバーに送ることができる。この機能により、ネットワークの帯域幅の節約、サーバー側の処理負荷の軽減、そしてデータの競合リスクの低減といったメリットが期待できるため、RESTful API設計において重要な役割を担っている。

詳細に説明すると、PATCHメソッドが生まれた背景には、PUTメソッドの持つ特性がある。PUTメソッドは、リソースの完全な置き換えを行う。つまり、クライアントがサーバーに対してPUTリクエストを送信する際、リクエストボディには更新後のリソースの「完全な状態」が含まれている必要がある。サーバーは受け取ったこの完全な情報で、既存のリソースをまるごと上書きする。これは、リソース全体が小さい場合や、リソース全体を書き換えたい場合には問題ない。しかし、リソースが非常に大規模である場合や、ごく一部のデータだけを変更したい場合に、リソース全体を送信することは非効率的である。たとえば、ユーザーが持つ多数のデータ属性のうち、ごく小さなフラグメントだけを変更する場合でも、PUTメソッドを用いると、全てのデータを含んだ完全なリソースをクライアントからサーバーへ送信し直さなければならない。これは、データ転送量が増え、結果として通信の遅延につながる可能性がある。また、部分的な変更であれば、サーバー側で元のリソースと送信されてきた変更内容をマージする処理が必要となるが、PUTでは単なる上書きであるため、このマージ処理はクライアント側で完全にリソースを取得し、修正し、完全な形で再度送信するという形になる。

これに対し、PATCHメソッドは、クライアントが変更したい「差分」情報のみをサーバーに送信する。サーバーはその差分情報を受け取り、既存のリソースに対して、その差分だけを適用して更新する。この「差分更新」というアプローチがPATCHメソッドの最大の特長である。クライアントが送信するリクエストボディには、更新後のリソースの完全な状態ではなく、どの部分をどのように変更するのか、という指示やデータが含まれる。

PATCHメソッドのリクエストボディに含めるデータ形式には、HTTP標準で厳密な規定があるわけではないが、一般的には「JSON Patch (RFC 6902)」や「JSON Merge Patch (RFC 7386)」といった形式が広く用いられる。JSON Patchは、追加 (add)、削除 (remove)、置換 (replace)、移動 (move)、コピー (copy)、テスト (test) といった具体的な操作を配列として表現し、非常に柔軟で強力な部分更新を可能にする。例えば、オブジェクトの特定のプロパティの値を変更したり、配列の要素を追加・削除したりする操作を細かく記述できる。一方、JSON Merge Patchは、よりシンプルに、JSONオブジェクトをマージする形式である。クライアントが送信するJSONオブジェクトは、既存のリソースにマージされ、指定された値で既存のプロパティが更新される。もし送信されたJSONオブジェクトのプロパティ値がnullであれば、そのプロパティは既存のリソースから削除される、というようなルールが適用される。どちらの形式を用いるかは、API設計者がAPIの複雑性、表現力、実装のしやすさなどを考慮して決定することになる。クライアントは、リクエストのContent-Typeヘッダで、使用しているパッチ形式をサーバーに通知する必要がある。例えば、JSON Patchであればapplication/json-patch+json、JSON Merge Patchであればapplication/merge-patch+jsonといったメディアタイプを指定する。

PATCHメソッドは、멱等性（べきとうせい）がない場合がある点も理解しておくべき重要な側面である。멱等性とは、ある操作を複数回実行しても、一度実行した場合と同じ結果になる性質を指す。PUTメソッドは、何度実行してもリソースが特定の状態に置き換えられるため、멱等性を持つ。しかし、PATCHメソッドは、例えば「数値に5を加算する」といった操作を差分として送信した場合、複数回実行するとその都度数値が加算され、異なる結果となるため、멱等性がない。ただし、JSON Patchのように「指定された値を置換する」といった操作を記述する場合、その操作自体は멱等性を持ち得る。このため、PATCHメソッドの멱等性の有無は、そのリクエストが具体的にどのような変更を差分として表現しているかによる。

サーバーがPATCHリクエストを処理した際の応答も重要である。成功した場合、通常は200 OKのステータスコードを返し、応答ボディには更新後のリソース全体、または変更された部分の情報を返すことがある。もし応答ボディに情報を含める必要がない場合は204 No Contentを返すこともある。エラーが発生した場合は、400 Bad Request（リクエストの形式が不正な場合）、409 Conflict（複数のクライアントからの更新が競合した場合）、415 Unsupported Media Type（サーバーがサポートしないContent-Typeが指定された場合）などの適切なステータスコードを返すべきである。

PATCHメソッドを実装する際には、サーバー側で部分更新のロジックを正確に処理する堅牢なメカニズムを構築する必要がある。また、複数のクライアントが同時に同じリソースを更新しようとした場合に発生する競合状態を適切に解決するための仕組み（例えば、ETagヘッダを用いた楽観的ロック）も考慮に入れるべきである。適切に設計・実装されたPATCHメソッドは、効率的でスケーラブルなAPIを提供するための強力なツールとなる。