(Web)APIについて再確認と発見したこと。

Web APIのマッシュアップからこっちの世界に来て、APIを作る側になったりしてきたので、これまで手がけてきたサービスはほぼすべてAPIの設計に関わってきたんですが、今回初めて人が考えた（クローズドな）APIを使う、それに修正していくという経験をして、WEB APIの設計について新たな発見や再確認をすることが出来ました。

粗結合であれ

アーキテクチャー的に一番重要なのがこれなんじゃないかと。APIのクライアント側がほぼ何のロジックもなしにシンプルにデータを受け渡し出来るようにする。インターフェースを変えない限り、クライアント-APIそれぞれ相手のことを考慮せずにカイゼンできるように設計するのがよいと。これはAPIの公開予定があってもなくてもそうだと思います。 要素１と要素２を文字列で結合して表示、なんてやっちゃいけない。

全体を俯瞰してみると、スマホアプリ等APIクライアントサイドはMVCのVだけに近い状態になっていくのかと思います。

レスポンスのフラット化

これまで自分がしてきた設計は構造化を意識してきたというか、クライアント側でそのまま連想配列に入れてグルグル出来るような、そんな感じだったんです。が、最新のプロダクトでAWSのCloudSearchを使って全文検索を実装したときに、今後はデータをフラットに返すような設計のほうがアーキテクチャーがシンプルになる気がしました。

CloudSearchにデータを投入するときはCSVやDynamoDBで入れます。データ投入がフラットだし、検索結果もそれに従ってフラットなスキーマのjsonで返せるから、そのままクライアントに返せるように設計すればAPIのレスポンスロジックを別途開発する必要がなくなります。

また、CloudSearchを使わないにしても、APIレスポンスがフラットなら、DB側もRDBじゃなくていいですよね。key-value-store系がそのままいけて、シンプルになる。 こうなると、データモデル=APIとなり、アプリ等のAPIクライアントはV+Cとなるから、mBaaSを採用した場合に近くなってきて、極論言うとフロントエンド側（クライアント側）のみの開発だけすれば良くなります。

いいこと尽くめだなあと。

全然まとまってませんが、次に設計をする機会があったらこんな思想を取り入れていきたいなあと、思ってます。