ActiveRecordとMySQLで少し複雑な検索のRailsAPIを作る｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
最近社内の福利厚生で、「年間10万円を上限とし、業務上必要、開発環境の効率化や新しい知識習得に役立つと考えられる電子機器やグッズの購入が可能」という【業務効率化周辺グッズ購入補助】なるものが発足し、さっそく夜な夜なAmazonで美味しそうなITガジェットがないか探索している前田です。 弊社では現在フロントサイドはAngularJS、サーバーサイドはrailsでAPIとCMS、というアプリケーションを開発しております。 私はrailsのサーバーサイドのAPI担当ということで、開発の際に詰まったところなどを備忘録がてら書いていきたいと思います。 rails歴の短い私めの備忘録が、少しでも読んでくださった方のお役に立てれば幸いです。 それでは早速タイトルにある通り、中規模程度のデータ量が入ったデータベースから、色々な検索に対応するロジックを書いていきます。 例として、全国チェーンになっている本屋
Web API設計指針を考えた｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
小文字のみを使用する。 単語をつなげる必要がある場合はダッシュを利用する。 単数形よりも複数形をつかう。なお、実装がRailsの場合でテーブルの複数形が誤っている場合には、URLは正しい複数形としてRails側を修正する。（APIに実装を反映させるべきではない。） スペルミスをしない。 URLの階層は浅く保ち、複雑さはクエリパラメーターに押しこむ。 クエリパラメータ名は配列で複数渡すものについては複数形、一つだけ渡すものについては単数形とする。 ページングにはper_page、pageというパラメータ名を使用する。 と書いてきたが、ただし、RESTには必ずしもこだわらず、あくまで利用側の利便性を重要視した設計とする。 1つの作業を完結するために複数回のアクセスを必要とするようなAPIの設計はChatty APIと呼ばれる。これはネットワークのトラフィックを増加させ、クライアントの処理の手間
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
