WebAPI設計におけるHTTPメソッドの決め方（GET, POST, PUT, PATCH, DELETE）

URIの基本

URIはリソースを示すもの。
メソッドはリソースに対する操作を示すもの。
以下に、Twitterの「いいね」に関するAPIエンドポイントを挙げる。

「いいね」関連のAPI
参考：TwitternのAPIドキュメント

GET /2/users/:id/liked_tweets
⇒ ユーザーが「いいね」しているツイートを取得する

POST /2/users/:id/likes
⇒ 特定のツイートに「いいね」する ⇒ 「いいね」を新規作成する

DELETE /2/users/:id/likes/:tweet_id
⇒ 特定のツイートの「いいね」を削除する

それでは、ひとつずつメソッドについて見ていこう。

GET

リソースを取得する際に利用する。
例えば、SNSで「投稿一覧を取得する」APIを考えると、以下のようになる。

GET /posts

POST

リソースを新規追加する際に利用する。
リソースの更新や一部変更は、別のメソッドを利用するのが好ましい。
SNSで「投稿を行う」APIを考えると、以下のようになる。

POST /post
※紛らわしいが、URIの/postは「投稿」の意味で使っている。

PUT

リソースを上書き/変更する際に利用する。
PATCHはリソースを一部変更する際に利用し、PUTと明確に使い分けが出来る。
SNSで「投稿を修正する」APIを考えると、以下のようになる。

PUT /post/:post_id

PATCH

リソースを一部変更する際に利用する。
PUTはリソースを上書きする際に利用し、PATCHとは明確に使い分けが出来る。
SNSで、「自身のユーザー情報の中の自己紹介文を変更する」APIを考えると、以下のようになる。

PATCH /:user_id/profile
たとえば、リクエストボディは以下のようになる。

{"introduction": "私の名前は津本です"}

すると、プロフィールの一部が変更される。

{
    "first_name": "津本",
    "last_name": "敏男"
    "introduction": "私の名前はツモトです"
    "image": "https://example.com/tsumoto.png"
}
↓
{
    "first_name": "津本",
    "last_name": "敏男"
    "introduction": "私の名前は津本です"
    "image": "https://example.com/tsumoto.png"
}

DELETE

リソースを削除する際に利用する。
例えば、SNSで「投稿を削除する」APIを考えると、以下のようになる。

DELETE /post/:post_id

この記事の注意点

メソッドの決め方と題していますが、正しく言えばRFC7231とRFC5789に従ったHTTPメソッドの決め方です。
実際に使われている大手のAPIでは、PATCHが使われていないこともあります。
RESTAPIではなくGraphQLのみをサポートすることも増えています。

実際に設計する際は原則を基本にしつつ、現在のデファクトスタンダードも調べて設計するようにしましょう。