そもそもWebAPIとは

WebAPIとは、

特定のURLに値とともにアクセスするとデータベースから必要なデータを取ってきてそれをクライアント（ユーザー側）にそのデータを送信する。

参考→エンジニア視点から見るWebサービスの全体像

WebAPIのデータフロー

下図のように設計した

Client→Route・・・ClientからAPIにRequestを送る
Route→Controller・・・RouteでURLを解析してControllerにDispatchする
Controller→Service・・・Controllerでデータを整理してServiceに投げる
Service→DB・・・ServiceはControllerから受け取ったデータをDBに格納する
DB→Service・・・ServiceはDBからの実行結果を受け取る
Service→Controller・・・ControlllerはDBに保存できたかどうかの結果をServiceから受け取る
Controller→Client・・・ClientはControllerからRequestに対してのResponseをjson形式で受け取る

ControllerとDBの間にServiceを入れた理由

MVCFrameworkにおいて、Controllerの役割は非常に多く、すべての処理をControllerに書くと肥大化してしまう。そこで、DBへのアクセスをServiceにまとめることで、処理をわかりやすく且つ再利用性を高めることができるようになる。

Routeの公開は必要最低限にする

RouteはClientから見るとWebAPIの玄関口であり、ここの間口を必要最低限にすることによりセキュリティ性を高めることができる。

Controllerでは細かいところまでエラー処理をする

ControllerはClientにResponseを返す役割があるので、エラー処理を細やかにすることによってClient側のRequestエラーをわかりやすくすることができる。

ServiceにDBを操作する処理をすべて書く

ServiceにはDBを操作する処理をすべて書く。特定のServiceを呼び出せるのは特定のControllerにすることにより、セキュリティ性を高めることができる。

DB構築について

下図のように構築してみた。

気をつけた点

データをDBから引っ張ってくるときになるべく別tableとjoinしないようにした
正規化をして、DBの拡張性を高めた

DBにおいて重要だと思ってること

DBから引っ張ってくるデータの量を最小化する努力をするべきだ。なぜならClientにResponseする際、データの総量が大きくなってしまうとどうしても通信量が増えてしまい、またClient側でparseするときに時間がかかってしまうからだ。

WebAPIのエンドポイント

エンドポイントとは、

WebAPIにおけるエンドポイントとは、APIにアクセスするためのURI

参考→Web API: The Good Parts

美しく設計することによって、別の開発者でも楽にアクセスできるようになる。

エンドポイントの実際の例

細かいエンドポイントの設計の仕方はいずれ記事を書きます。

UnitTest

UnitTestは文字通りテストコードでWebAPIにおいてはそれぞれのURLは正しく使えるかということを確認することができ非常に有益だと思う。また、機能拡張やソースコードのリファクタリングをしたときに正常に動くかどうかを自動でテストすることができる。また、エラー処理したコードが正常に動くかもテストできるので非常に便利だ。

また、きちんとテストコードを書くことによってドキュメント代わりにもなり、別の開発者からもわかりやすくなる。

参考までに実行したときのCUIを載せておく

最後に

試行錯誤して学んだ知識なので間違いがあるかもしれないし、さらに良い設計方法もあるかもしれません。

コメントで批判していただけると嬉しいです。