RESTful API開発における5つの重要なHTTPメソッドとは：POST、PUT、PATCH、GET、DELETEの5つ

開発者が知っておく必要がある5つの一般的なRESTful API HTTPメソッドについて、方法の違いと使用方法を解説する。

[Tom Nolle，TechTarget]

　HTTPベースのAPIはRESTful Webサービスと簡単に統合できるが、多くの場合、非論理的で重複し、非効率的であるように見える。HTTPメソッドを使用する方法は数多くあるが、その多くはRESTful原則と互換性がない。APIを構築する際にRESTまたはHTTPの原則に厳密に従うことがいかに重要であるかについても、長年議論されている。

　誤解や誤用が生じることが多いため、HTTPにおけるAPIメソッドを確認し、リソースやリソースコレクションでそれらを適切に使用する方法を理解することが重要だ。本稿では、リソースとリソースコレクションの主な違いを簡単に紹介してから、RESTful API開発に関わる人が知っておくべき5つの基本的なHTTPメソッドを検討する。

HTTPリソースとリソースコレクション

　HTTPリソースはデータファイルに相当する。開発者はリソースのコンテンツを読み取り、更新できる。リソースはサーバ上でホストされ、URLを介してアドレス指定できる。リソースコレクションは、関連ファイルのセットとして表示できる関連リソースのセットだ。この記事で検討するメソッドは、リソース、リソース コレクション、またはその両方に対して操作できる。

　コレクション内のリソース間の関係は、コレクションをサポートするソフトウェア、具体的にはそのソフトウェアの実装に依存する。ファイルは、さまざまな方法で連結したり、ツリーに配置したり、順序付けしたりできる。実装がクライアントの動作に何らかの指示された順序を割り当てていない場合、結果として生じる多重度により不一致が生じ、アプリケーションが停止する可能性がある。

方法1：POST

　POSTは、主にリソースコレクションを操作する唯一のRESTful API HTTPメソッドだ。コレクション内に下位リソースを作成する場合、親リソースにPOSTを適用すると、新しいリソースを作成し、それを適切な階層に関連付け、後で参照できるように専用のURLを返すように求められる。ただし、POSTはべき等（結果が操作回数の多寡によって変化しない）ではないことに注意してほしい。この方法を複数回使用して、一貫した結果を期待することはできない。

　POSTの大きな利点は、開発者がリソースを明示的に定義できることだ。この機能は、コードを汚染したり、参照を混乱させたり、アプリケーションに問題を引き起こす原因となる下位リソースをチームが誤って作成することを防ぐのに役立つ。

方法2：PUT

　POSTに相当する単一リソースはPUTで、コンテンツ全体を置き換えることによってリソースを更新する。RESTful APIのHTTPメソッドであるPUTは、リソース情報を更新する最も一般的な方法だ。

　PUTメソッドを使用してリソースを作成することは可能だが、このアプローチには、上述したように、リソースを誤って作成するリスクが伴う。PUTがリソースのコレクションに適用されると、リソースコレクション全体が置き換えられるが、これは通常は意図したものではない。

方法3：PATCH

　PATCHは、リソースの更新に使用されるもう1つのHTTPメソッドだ。PUTメソッドのようにリソースを置き換えるのとは対照的に、PATCHはリソースの内容のみを変更する。原則として、これらの変更はJSONやXMLなどの標準形式で表現する必要がある。

　PUTと同様に、リソースコレクション全体にPATCHメソッドを適用することは、適切な方法ではない。つまり、そこに含まれる全てのリソースを本当に更新するつもりがある場合を除く。

方法4：GET

　最も一般的なHTTPメソッドはGETで、リソースのコンテンツとデータの表現ビューを返す。GETは読み取り専用モードで使用する必要がある。これにより、データが安全に保たれ、リソースのべき等が維持される。途中で別のクライアントによって変更されない限り、このメソッドを何度使用しても、同じ結果が得られる。

　GETメソッドはリソースの内容を変更するために使用されることがあるが、これはメソッドの使用方法が不安定だ。PATCHクライアントが最後にGETを実行してからリソースが変更を検出すると、クライアントのリソースへのPATCH機能が侵害されるのが一般的だ。

方法5：DELETE

　最後のHTTPメソッドはDELETEだ。DELETEメソッドが単一のリソースをターゲットにすると、そのリソースは完全に削除される。

　通常、DELETEの実装には一貫性がない。実際のリソースが存在しない場合でも、リソースのURLは利用可能なままである可能性がある。このタイプのシナリオでは、サーバまたはリソースの実装がURLを使用して消滅したリソースの状態を変更し、後続のDELETE実行に対して異なる反応を示す可能性がある。

　確かに可能ではあるが、リソースコレクション内の全てのコンテンツが削除されるため、リソースコレクションでDELETEメソッドを使用することは基本的に避けないといけない。このメソッドはべき等ではないため、そのように扱うべきではないことに注意を払う必要がある。