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
みんな一度は考えるやつですね。
そこでQUERYメソッド！
と思ったらもう書き込みありましたね🙇♂️
弊社の技術ブログを紹介
HTTP検索条件、GETにするか？POSTにするか？ | フューチャー技術ブログ
GET を使う場合は、それへのリンク (GET) があったときにブラウザがそれを先読みすることがあるかもしれない、検索エンジンがクエリパラメータ込みのリンクを踏みにくるかもしれない、それを (パラメータ等によっては) キャッシュされてもよいと解釈されるかもしれない、クエリパラメータが URL として可視化され履歴に残るかもしれない、などの実用上の注意事項は頭に置いておいたほうがいいかもしれません。それも踏まえた上でどちらを選ぶか、かなと。
外資IT営業の給与ガイド
#給料
#営業
外資IT営業の給与体系・株式報酬、期待できる年収値や上がり幅を、WorkCircleのユーザー様且つパートナー企業チャレンジャーベース社市川さんと、外資エンタプライズ向けソフトウェア(SaaS)営業の経歴を持つ西村さん共同で記事にしました。
RSU完全ガイド(確定申告用スプレッドシート付き)
#給料
外資企業で多く採用される給与の一つ、RSUの構造や仕組み、リスクや確定申告方法に関してWorkCircleのユーザー様、且つパートナー企業チャレンジャーベース社代表の市川さんと紹介します。
外資・日系IT企業のRTO(オフィス出社)状況リスト
各企業のRTO(オフィス出社)状況をリスト化しました。 提供元データは所属企業が証明されているWorkCircleユーザーによるものです。 希望する働き方や転職先を決める軸の一つとして、是非参考にしてください！
