RESTの原則の１つである、Uniform InterfaceによるとGETはデータの参照、POSTはデータの追加•更新に使用するとされています。
ここで、疑問があります。
検索機能などでデータを送信して、その結果を参照する場合、このような機能はGETメソッドで定義すべきなのでしょうか？
しかし、フレームワークによっては、GETメソッドではBodyにデータを含めてリクエストを送信できなかったりします。そうなると参照目的にも関わらずPOSTメソッドで定義しなくてはいけません。
この場合、RESTの原則から外れているのでしょうか？
(REST自体がデファクトスタンダードになっているだけだから、基本指針で行こうくらいで良いんですかねー。
正直、これはRESTの原則から外れてるとは言えないと思います🤔
というのも、検索って「参照」の一種だけど、検索条件という「入力」も必要ですよね。
GETメソッドだと:
- URLの長さ制限ある
- 検索条件が丸見えになっちゃう
- 複雑な条件を送るのが結構めんどくさい...
なので実際のプロジェクトでよくあるのが:
- シンプルな検索（IDとか）→ GET使う
- ガッツリした検索条件 → POSTでやっちゃう
POST /search とかにしちゃうの、よく見かけます！
これ、REST原則に反してるって言われがちですけど、実用性考えると全然アリだと思います👍
結局のところ、チームで「こうしよう！」って決めて、ちゃんとドキュメント書いておけばOKじゃないですかね〜
コメントありがとうございます！！
＞検索って「参照」の一種だけど、検索条件という「入力」も必要。
そうなんですよ〜。
あと、再度一次情報？RFCでHTTPにおけるPOSTメソッドの基本定義を確認してたら、どこにもデータの追加•更新、とは書いてないですね。
https://triple-underscore.github.io/RFC7231-ja.html#section-4.3.3
POST メソッドは、［ ターゲットリソースが，自前の特有な意味論に則って，要請内に同封された表現を処理する ］ことを要請。するためのもの、と考えると理解できそうです！！！！！
日本語で分かりやすく説明する時に、データの追加•更新用のメソッドです。っと言われるから混乱してたみたいです！
助かりました🙇♂️
restの原則という物自体が標準化されているわけではないので曖昧です。
一般的なrestの原則は、個人的には意図的に破ることはありますね。
例えば上記のような検索の場合にget,post両方検討してみたり、何かしらの複雑な変更(ビジネスロジック)を伴うものは動詞を使うことを検討してみたり。
でも、こうとも書いてるなあ。。
やはり、理想は参照系のメソッドはGETを使って、細かい検索処理はクエリパラメータを渡して実装すべきなのか。。
https://triple-underscore.github.io/RFC7231-ja.html#section-4.3.1
GET は、情報を検索取得する主たる仕組みであり，ほぼすべての処理能 最適化の力点が置かれる所である。 よって、誰かが［ HTTP を介して識別できる何らかの情報を検索取得する ］ことについて話すとき，たいていは GET 要請を為すことを指している。
GET+URLパラメーターで無いとURLで再現できないので、検索結果や検索条件を共有できなくて困る場面が多くて不便な場面が多いです。
「共有はしない」と言う前提ですか？
本当にそうでしょうか？
前の画面から戻ってくる時とかにポストの条件を組み立てるのが不自然だったりしませんか？
システムのアーキテクチャを設計する上で、前提は必ず覆る前提で考えた方が自分たちの身を守れます。
そもそもその前提は本当にビジネスにとってクリティカルな前提ですか？自分たちが勝手に都合よく決めた前提ではありませんか？
フレームワークがGETのBODYにデータを含んでくれないのは当たり前です。意味がないので。
まず実用上の話ではなく原理原則の話をするならば、フレームワークは、GETがbodyを受け取るのを妨げること自体はあまり良くないですね。
RFC2616
>A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
RFC7231で、まあそういう実装もあるけどねって内容は書いてありますけど。
>A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
実用上としては、ブラウザ上のアプリなのかスマホアプリなのかで全然違うと思いますね。
GETの文字数の制限もブラウザ側独自の制限な気がします（RFCに記載されてたらすいません、見落としです）。
あと仮に文字数の制限があったとしても、多くのユースケースで問題ない値なはず（ホテルの予約や家探しなどの複雑なケースでも）と思うので、基本的には素直にGET使うのが良いんじゃないかでしょうか。その制約が問題になって、GET関連の技術的制約が障害になった時にPOSTに変えればいいくらいの印象です。
あと今後の話をすると、QUERYメソッドが妥当になるかもしれないですね、
https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-method-w-body.html
