2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

GETとPOSTの違いを安全と冪等を踏まえて説明

Last updated at Posted at 2024-02-07

お疲れ様です。翔太です。
今回は、GETとPOSTの違いについて、まとめていきたいと思います。

GETとは

指定したリソースの表現を転送するようにリクエストするメソッドです。
何が情報を検索したり取得するために使います。

例えば、ブラウザでURLを入力し検索するときには、GETメソッドを使っています。

また、仕様で安全かつ冪等(べきとう) であると定義されているため、基本的に読み取り専用な機能に対して使うべきメソッドになる。

GETを使うとどのような処理をしていたとしてもクライアントには安全なAPIだと
見なされます。

これは、クライアントからはサーバがどのような処理をやっているかを知ることはできないためです。

POSTとは

POSTは指定したリソースを実装した機能に従って処理をする機能になります。

主に登録処理や更新処理などの書き込みがあり、リソースが更新される可能性のある処理に対して使うメソッドになります。

例えば、以下のような例があります。

  • HTMLの <form></form>に入力された内容をDBへ登録する
  • ブログの記事を投稿する
  • 新しいユーザを登録する
  • 既存のデータに新しい情報を付加する

また、GETとは反対に冪等でないかつ安全でないと定義されています。

HTTPメソッドにおける冪等、安全、副作用とは何か

ここまでの話で、冪等と安全って何?って思いませんでしたでしょうか?
私は無茶苦茶思いました。POSTは安全じゃねーの?、冪等ってそもそも何?ってね
なので、ここでは、冪等と安全、そして、それを説明するのに必要な副作用について説明していきたいと思います。

副作用とは

安全と冪等を語る上で重要な表現であるため、ここで解説します。

クライアントにより意図されたものを「主たる作用」と言います。
逆に、クライアントにより意図されていないものを副作用とする。

つまり、クライアントによって意図されていない動作や状態の変化、データの揺らぎなどが起こってしまうこと全般を副作用が生じると言います。

安全とは

HTTPリクエストメソッドにおける「安全」とは、「リソースの状態を変化させない読み取り専用であること」を言います。

それ以外の作用は副作用であり、制限もかけられず、責任も負えないものとされてる。

そして、「安全」を定義する目的は、クローラーや、キャッシュ機構のパフォーマンスを正常に機能させることや、クライアントに「リソースの状態の変化」を伴う作用と伴わない作用の区別を事前に知らせることができるようにするためとされています。

つまり、「安全」とは、「リソースの状態に変化が生じることのない」メソッドです。
例えば、GETはリンクにリソースを含み、ブラウザに設定することでリクエストを送ると、受け取ったサーバはそのリクエストに応じたデータを何のデータの変更もせずにレスポンスで返却する。

これは結果として、サーバ側でデータをいじることがないため、サーバ側に何の危害も与えることのない安全なメソッドであると言えます。

リソースの状態の変化って何だよと感じる方もいらっしゃると思うので説明しておくと、
サーバー側が用意したデータに対してリクエストの内容によって、変更を加えてレスポンスとして返すことリソースの状態の変化 と言います。

逆にPOSTなどの処理は、サーバー側でデータの状態の変更(データを追加、更新、削除)される可能性があるため、安全とは言えません。

安全メソッド:

  • HEAD
  • GET
  • OPTIONS
  • TRACE

冪等とは

HTTPリクエストメソッドにおける「冪等」とは、「同一パラメータで1回以上リクエストしても、リソースの状態が同じであること」をいいます。

それ以外の作用は副作用であり、副作用も実装可能とされます。

もしクライアントがサーバーからのリクエスト成功の応答を受信する前に通信障害が発生した場合、クライアントはリクエストを再度送り、そのリクエストの目的を達成する必要があります。
サーバーはそのリトライによるリソースの不整合から保護しなければなりません。
さらに、クライアントは、同じリクエストを再度送るとリソースの整合性が破壊されるとなれば、リトライはできなくなるでしょうし、そのリトライによりリソースの整合性が保護されるのか、破壊されるのかを知らなければ無闇にリトライもできなくなるでしょう。

したがって、サーバーはこのような堅牢性を確保するとともに、クライアントにリトライ可否の区別を知らせなければなりません。

つまり、クライアント側からリクエストを再送した際にデータが変わる場合、得たいデータが取得できなくなってしまう。
また、もしリクエストを再送することで、データが変更されてしまう可能性があるとなれば、リクエストの再送ができなくなってしまうと言うことです。

冪等メソッド:

  • PUT
  • DELETE

HTTPメソッドにおける安全かつ冪等であるとは何を指すのか?

簡単に言うと、同一のパラメータで1回以上リクエストを送った場合に、リクエストに応じたデータを何のデータの変更もせずにレスポンスとして返却する。

そして、その返却したリソースの状態が前回と同じ結果であることが安全かつ冪等といえます。

結論(GETとPOSTの違い)

上記の話でわかったと思いますが、GETは冪等かつ安全、POSTは逆に、冪等ではないし安全ではありません。

つまり、簡単に言えば、クライアントがリクエストを送信する際に、
同一のパラメータで1回以上リクエストを送った場合に、リクエストに応じたデータを何のデータの変更もせずにレスポンスとして返却する。」と言う条件に合うならば、GETメソッドを使う。そうでないならば、POST(PUTやDELETEなどもあります)を使ったらいいと言うことになります。

上記の理由から、GETメソッドは検索などで使われますし、POSTメソッドは、データベースの更新処理などに使われるわけですね。

また、HTTPメソッドには、キャッシャブル(キャッシュ可能)かどうかがメソッドごとに定義されています。
GETはキャッシュできますが、POSTはキャッシュできないこともあるため、そう言う点においてもGETの方が適しているとしてGETメソッドを用いる場合もあります。

参考サイト

https://qiita.com/kanataxa/items/522efb74421255f0e0a1
https://qiita.com/KyojiOsada/items/9c8db9714a0c9c72823c

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?