アプリケーションとのルールを決めよう
アプリケーションとのルールを決めよう
前回はローカル環境にDB,Webサーバーを作成したところまで出来ました。
今回は設計をするためにルールを決めるところまで行きたいと思います。
アプリケーションとの通信
通常のソーシャルゲームは、サーバーとあらゆる通信を行っています。
大枠の考え方の基本としては、
- 認証系通信
- 通常系通信
- デバッグ系通信
- 外部連携系通信
- アセット系通信
となると思います。
認証系通信
アプリケーション上のユーザーが本人であることを確認するための通信です。
この目的としては、
- 本人であることを確認すること
- その後の通信の暗号化方式のルールを決める
となります。
「本人であることを確認する」ことが一番の目的ですが、実は「その後の通信の暗号化方式のルールを決める」ということもセキュリティ的にはとても大事です。
何故なら、通信の暗号化は「ユーザー毎に異なり、かつ可変であるべき」だからです。
この辺は不正検知を詳しく話す機会があれば記載しますが、今は「必要なんだー(´・ω・｀)」程度に収めておいてください。
通常系通信
主にデータベースの状態や情報を取得するための通信です。
ログインボーナスを受け取ったり、イベントのデータをとったり...
まさに、通信の大多数を担うところです。
デバッグ系通信
内容は通常系通信とほぼ同じですが、これはデバッグ用としてしか使用しません。
つまり、本番環境（正規のアプリケーション）では使用できません。
考え方とルール次第では、これは使用しなくとも大丈夫です。
外部連携系通信
例えば、TwitterやFaceBookといった、自分のアプリケーション以外のサーバーとの連携用です。
ここでは通常系通信と異なる方式で通信をしなければならないため、認証系・通常系とは別のルールで通信を行います。
ルールは、外部サイトによって異なるので、今回は割愛します。
アセット系通信
アプリケーションに画像を乗せると、容量が膨れ上がったり、画像を変更する際にアプリケーションのバージョンを上げなくてはならなくなります。
そうしないためにも、アプリケーション外に画像を載せて管理する必要があります。
そのために、アセット（画像とか）を外部サイトに置いておきましょう。
最近のスマホゲームだと、よく下記の様にダウンロードする画面を見るかと思います。
iTunes Store、Google Store共に、スマホからのダウンロードにはある程度制限があります。
アプリケーション自体のダウンロード時に、特定のダウンロード容量を超えるようなものはWiFi通信を義務付けるため、ダウンロード数を稼ぐときにも必要となります。
※企業のアプリではほぼ確実に必要となると思います。
次回は、認証系通信から実装していきましょう。
