Edited at

WebAPIの設計から実装まで〜設計編〜

More than 3 years have passed since last update.

WebAPIを設計から実装までした時に考えたことや書いたコードをまとめていく。

今回は設計思想について

実装編書きました→WebAPIの設計から実装まで〜実装編〜

GitHubのレポジトリ→chat_app


そもそもWebAPIとは

WebAPIとは、


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


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


WebAPIのデータフロー

下図のように設計した

スクリーンショット 2016-05-27 10.07.42.png



  1. ClientRoute・・・ClientからAPIRequestを送る


  2. RouteController・・・RouteURLを解析してControllerDispatchする


  3. ControllerService・・・Controllerでデータを整理してServiceに投げる


  4. ServiceDB・・・ServiceControllerから受け取ったデータをDBに格納する


  5. DBService・・・ServiceDBからの実行結果を受け取る


  6. ServiceController・・・ControlllerDBに保存できたかどうかの結果をServiceから受け取る


  7. ControllerClient・・・ClientControllerからRequestに対してのResponsejson形式で受け取る


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

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


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

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


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

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


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

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


DB構築について

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

SNSApplicaitonModelStructure.png


気をつけた点


  • データをDBから引っ張ってくるときになるべく別tablejoinしないようにした

  • 正規化をして、DBの拡張性を高めた


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

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


WebAPIのエンドポイント

エンドポイントとは、


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


参考→Web API: The Good Parts

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


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

スクリーンショット 2016-05-27 11.28.18.png

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


UnitTest

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

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

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

スクリーンショット 2016-05-27 11.43.39.png


最後に

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

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