RESTful API の時、検索はどうする？ – StackOverFlow の回答を読んでみる

みなさん、こんにちは。どんぶラッコです。

今日は RESTful API 設計のときに、検索APIをどうするかというテーマについてお話ししたいと思います。

RESTful API とは何か？については↓↓のページをご確認ください。

この記事にも書いてあるように、URLで名詞を、HTTPメソッドで動詞の役割をはたしています。

• /books GET … 本の一覧表示
• /books POST …. 本の新規作成
• /books/{id} GET … 本の個別情報表示
• /books/{id} PUT … 本の個別情報表示
• /books/{id} DELETE … 本の個別情報削除

このような設計の時、本を検索するAPIの窓口はどこにするか、迷ったことはありませんか？

そこで、今回はStackOverflowの回答を例に、みなさんがどのように対処しているかを見ていきましょう！

Stack Overflow の回答例を見てみよう

/search をリソースとして定義してしまえ派

一番多く票を集めているのは、 search 自体もリソースとして捉える方法です。その場合のメソッドは POST としています(検索を作成しているから、だとか)。

ただしPOSTを使うと検索結果をブックマークできないということが指摘されています。

この点については POSTした結果を保存し、その結果を表示すればいいとしています。

/search/XXXXXX GET ということですね

どんぶラッコ

コメントの中には「なんでこれが一番評価が高いのか全くわからない」というコメントもあります。
筆者としてもちょっと違和感があります

GET通信 としてパラメータを渡す

こっちの実装をする方が多いのではないでしょうか。

GET通信のパラメータとして検索条件を渡す方法です。

ただし、その設計方法は人によってさまざまです。

こちらの記事で紹介されているパラメータの設計方法をご紹介しますね。

まずは直接渡す方法

/book?var1=xxxx&var2=xxxx

Laravelでの実装方法を紹介している例もあります。

/books?filters[status_id]=1&filters[author]=Hoge&page=2&include=relatedResource

ただし、この実装方法の場合、 [] がブラウザによっては読み取れないという指摘もあります。

また、こんな書き方もありました

/books?filter=param1%3Dvalue1%26param2%3Dvalue2

%3D は = ですね

私は結局シンプルにGET通信パターンの一番最初のものを使うことが多いです。みなさんはどうしていますか？