HTTPのメソッドについておさらいしようとしたら、奥が深かった。って話。

きっかけ

Twitter上で、全部GETでやりゃいいじゃん、的な言葉を見たので、
改めてちゃんと調べてみようと思った。

HTTPのメソッド

1. GET
   指定されたリソースの表現を取得するために使用される。
   URIから中身を取得するだけで、変更することはない。

2. POST
   新しいリソースを作成するために使用される。
   通常、リソースを作成、更新、または削除するときに使用され、
   サーバーが作成した新しいリソースののURIを取得する。

3. PUT
   指定されたURIのリソースを置き換えるために使用される。
   リクエストのボディにリソースの内容が含まれ、
   指定されたURIでリソースが存在する場合は置き換え、
   存在しない場合は、新しいリソースを作成する。

4. PATCH
   指定されたURIのリソースを部分的に更新するために使用される。
   リクエストのボディに更新の部分があり、
   指定されたURIのリソースを部分的に更新する。

5. DELETE
   指定されたURIのリソースを削除するために使用される。
   URIのリソースを削除し、削除に成功した場合は
   204 No Contentステータスコードを返す。

6. HEAD
   GETメソッドと同じように動作するが、レスポンスボディを含まない。
   指定されたURIのリソースが存在するかどうかを確認するために使用される。

7. OPTIONS
   指定されたURIに対するHTTPメソッドのリストを取得するために使用さる。

※まだ他にもあるけど、今回は主要なやつだけ

調べていく中で思い出したこと

インターネットの歴史みたいな本か何かで、HTTPを設計したとき、
ブラウザ（開発当時はそういう概念はなかったが）からファイルの操作ができたらいいな、
という、
狙いがあったって話を思い出しました。

それがあって、プログラムでやってるような
ファイル操作(GET, POST, PUT, PATCH, DELETE)や
違うサーバー間でやり取りするための情報取得(HEAD, OPTIONS)なんて
メソッドが生まれたのかと思いました。

個人的なプロジェクトでAPI部を改良しているのですが、
記載データを修正するときに
　元データを修正 →　JSON化
　 → バッファサーバー（と呼んでる一時置き場）更新（※API返答コンテンツ）
という流れでやっているのを
HTTP経由でPATCHで置き換えるなんてこともできるのかな、
なんてことを考えました。

いままでPATCHやOPTIONSの存在に気づいてなかったんで、
なにか機会があったらいじってみようかと。

参考

RFC 9110: HTTP Semantics