アプリのweb APIをRailsで作った時のアンチパターン
①エラーメッセージしっかり作りこまなくても意外と大丈夫
HTTPエラーコードはRailsが勝手に吐いてくれるので(Not FoundとかUnauthorizedとか)、小さいチームでサーバもアプリも作る場合は意外と大丈夫。
②配列の書き方統一する
has_manyのデータの列挙の書き方とModel#indexのデータの列挙の書き方が違ってたりする。
users#indexとかで取ると
{
age:30
gender:female
},
{
age:20
gender:male
},
みたいにカラムのみの列挙の一方で、has_many friendsを埋め込むときは
{
age:20
gender:male
friends:{friend:{age:30...}}{friend:{age:20...}}
},
要素ごとにmodel名入ってたりして非対称になってるとか。
③最初から汎用的なAPI目指さずに、アプリで使いやすい書き方とか、具体的なドキュメントの書き方する
いきなり外部ユーザの利用を見込んで無理に完全にRESTであったり、抽象的なドキュメント作らなくていい。わかりにくくて生産性落ちる。ドキュメントにはアプリのどの画面でどうやって使ってるとかまで書いちゃっていいと思う。
④OAuth2とかまで作りこんでしまう
理想的にはやるべきなんだけど、（僕みたいな）技術力があまりない場合は無理せず負荷のない認証方法採用する。認証なくてもよければやらない。
OAuth2とかまでやっちゃうと試しに叩いてみるのも結構たいへんになっちゃうので、がっつり作りこむ必要なければ最初は見送る。
認証とアプリのマルチスレッドなんかが絡むとかなり複雑なことになる。認証ってユーザにとってメインの価値ではない。
⑤rablとか使って書くと便利なんだけど気をつけて書かないとパフォーマンス落ちる
n+1問題にも注意
⑥静的なデータはrails使わなくても、テキストファイルに固定のjson書いてS3にでもおいておけばOK
例えば、アプリに更新があったかを示すjsonとか
latest_version: "1.2.0"
とかだけのために、バカ正直にrailsでModel作ってテーブル作ってデータ登録してってやってたけど、そんなに更新されるもんじゃないし、更新されても手作業で書いたほうが早いってやつは、ただのテキストでつくっておいておけばよし。
更新チェックだと毎回アプリ起動時に呼ばないといけないので、テキスト化すればパフォーマンスもあがる。
S3もcloudfront(CDN)組み合わせれば早いしパフォーマンス落ちないからいいコトだらけ。
