脱RESTful API設計の提案
•Télécharger en tant que PPTX, PDF•
14 j'aime•14,126 vues
RESTful APIであることにこだわらなければ皆（主に開発者）がハッピーになれるかもしれません。
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (13)
Similaire à 脱RESTful API設計の提案
Similaire à 脱RESTful API設計の提案 (20)
脱RESTful API設計の提案
- 2. はじめに この資料は、アプリの開発にあたって、どの機能をアプリで提供し、どの機能はAPIサーバで提供 するべきか、そしてそのAPI設計の粒度をどうするべきかという問題に対する回答の一つを示すも のです。 この資料においてはソーシャルゲームでの利用を例としています。 corporate data center フロントアプリ ・ブラウザ APIサーバ 通信 RESTful APIがよく利用される
- 3. フロントアプリ スタンドアロンゲームの構成要素(例) グラフィック アニメーション サウンド レベルアップ戦闘ルール 評価・報酬 シナリオ ゲームシステム・基本ルール 演出 セーブ・ロード 全ての機能はフロントアプリに実装される
- 4. ソーシャルゲームになって構成要素が増えた 各種 マスタリソース 追加シナリオ イベント配信 アカウント 引き継ぎ 会員登録 多端末 同時利用 運営から アカウント凍結 アプリ上データ アカウント関連機能 会員 セーブデータ データ管理機能 各種ログ管理 フレンド 登録管理 （準）課金機能 その他運営機能 連続ログイン 報酬 課金管理 アイテム ガチャ管理フレンド連携 報酬管理 報酬付与 グラフィック アニメーション サウンド レベルアップ戦闘ルール 評価・報酬 シナリオ ゲームシステム・基本ルール 演出 セーブ・ロード どの機能をゲームサーバに持たせるか？どう利用させるか？
- 11. 実装してみた 命名：T8エンジン
- 12. ゲームサーバ フロントアプリ 「アイテム購入API」を準備しないかわりに、 「課金アイテム消費API」 「アイテムGET API」 「現在の保有アイテム取得API」 を同時にコール出来るようにする。 T8エンジン 利用例 体力全回復 API課金アイテム消費API アイテムGET API 現在の保有アイテム取得 API 会員データ更新 API メッセージ送付 API アイテム購入 API × その他、単機能のAPI
- 15. 本音 • サーバ側でゲームロジックの実装をすると面倒くさい。 • インタラクティブなゲームとなるとより面倒な結合が増える。 • サーバの通信回数も負荷もできるだけ抑えたい。 • ロジックがフロントによると利用ユーザーが増えても、サーバの負 荷が増えにくいので負荷設計が楽。 • 要件がよくわかんないから、イベントに対する膨大な組み合わせの APIの実装なんてやってられない。
- 17. ゲームサーバフロントアプリ サーバ側はどうしてもサーバでやらないと ならない部分の開発に注力できる。 各種 マスタリソース 追加シナリオ イベント配信 アカウント 引き継ぎ 会員登録 多端末 同時利用 運営から アカウント凍結 通信 アプリ上データ アカウント関連機能 会員 セーブデータ マスタデータ管理機能 データ管理機能 各種ログ管理 フレンド 登録管理 （準）課金機能 その他運営機能 連続ログイン 報酬 課金管理 アイテム ガチャ管理フレンド連携 報酬管理 報酬付与 グラ フィッ ク アニ メー ション サウン ド レベル アップ 戦闘 ルー ル 評価・ 報酬 シナリ オ ゲームシステム・基本ルール 演出 セー ブ・ ロード
- 18. メリットだらけに見える
- 19. デメリットは？
- 20. デメリット 1. 複数のAPIを同時コールできるようにするために、インタフェイスが RESTful APIでなくなる。 2. アプリや通信をクラックされた時にチートをされやすくなる。
- 21. デメリット１ 複数のAPIを同時コールできるようにするために、 インタフェイスがRESTful APIでなくなる。 どうしてもRESTful APIである必要がある場合、間にプロクシサーバを立てる必要 がある。 同一のHTTP リクエストで投げる ゲームサーバ フロントアプリケーション プロクシサーバ 課金アイテムを消費して アイテムをGETして、 現在のアイテムを取得する API 課金アイテムを消費して アイテムをGETして、 現在のアイテムを取得したい RESTful APIとし て作る。 RESTful APIではない。 課金アイテム消費API アイテムGET API 現在の保有アイテム取得 API
- 28. トランザクション処理が利用できないシステムだとどうなるか？ 体力全回復 API 課金アイテム消費API 100コイン使え API実行 ゲームサーバフロントアプリケーション アイテムGET API 現在の保有アイテム取得 API ← OK API実行 ← OK API実行 ← OK API実行 体力減らす API 課金アイテム戻すAPI 100コインAPI API実行 途中で通信に失敗したら、それまでのAPI実行をキャ ンセルする為のAPIをコールしなければならない。 →どこまで成功したかを把握する必要がある。 →キャンセルAPIも失敗する可能性がある。 無理ゲー… もしNGだっ たら？ キャンセルが NGだったら？
- 33. try{ begin_transaction( Database1 ); データ処理1( Database1 ); データ処理2(Database1 ); データ処理3(Database1 ); commit_transaction(Database1 ); catch Exception(){ rollback(Database1) } 単一のデータソースにおけるトランザクション処理の担保方法 →データ処理1~3のどこで失敗しても、commit_transaction([to Database1] )が実行されないかぎり、 どんなデータ処理を行ってもそれらはロールバックされる。(データ処理を行う前の状態に戻る) ※rollbackを記載していなくても、commitされない限り、rollbackされる どんな例外でもとにかく元の状態に戻せ トランザクション開始宣言 トランザクション終了宣言
- 35. try{ begin_transaction( Database1 ); データ処理1(Database1 ); begin_transaction( Database2 ); データ処理2( Database2 ); データ処理3( Database1 ); commit_transaction( Database2 ); commit_transaction(Database1 ); catch Exception(){ rollback( Database2) rollback( Database1) } 複数のデータソースにまたがるトランザクション処理の担保方法 →begin_transactionとcomimt_transactionを入れ子にすることで、全体をトランザク ション処理することが可能。 トランザクション開始宣言 どんな例外でもとにかく全部もとに戻せ トランザクション終了宣言
- 36. →複数のデータソースをまたがる事も可能なの で、DBのシャーディング(水平分割)にも対応可能。 マスタDB ユーザーDB1 ユーザーDB2 ユーザーDB3 更新があったDBの みcommit 更新があったDBの みcommit ユーザーDB4
- 40. try{ begin_transaction(Database1 ); データ処理1( Database1 ); データ処理2( Database1 ); データ処理3( KVS_Key1 ); commit_transaction( Database1 ); catch Exception(){ delete( KVS_Key1) rollback( Database1) } 複数のデータソースにまたがるトランザクション処理の担保方法 →ロールバック用のブロック中で、更新対象となったKVSのキーを削除すれば、次 回のリクエスト時に新たにデータが作成される。（疑似的なロールバック） トランザクション開始宣言 更新対象となったデータを消す トランザクション終了宣言 Database1に関しては更新前に戻す
- 46. HTTPリクエスト例 curl - -X POST "${HOST}/${VERSION}/gameapi" -H "Content-type: application/json" -d " ${JSON_BODY}"; →一般的なHTTPリクエスト方式 但し、リクエストメソッドは全部POST
- 47. JSON_BODY部分 { “token” : “user_idとnonce, user_secret, 時刻等から生成した認証用token”, “user_id” : “user_id”, “nonce” : “ランダム文字列”, “body” : [ { “api_name” : “課金アイテム消費API”, “api_id” : “課金アイテム消費API_01”, “params” : {“use_num” : 100} }, { “api_name” : “アイテム付与API”, “api_id” : “アイテム付与API_01”, “params” : {“item_id”: 10, “num” : 5 } }, { “api_name” : “アイテム取得API”, “api_id” : “アイテム取得API_01”, “params” : {“item_id”: 10 } } ] } ※user_secretは予めサーバとアプリ 間で共有しておき、tokenを生成する ために使用されるが、通信ではやり 取りされない。 ※api_idはレスポンス中でapiを特定 するために利用するため、一意であ れば何でも良い。
- 48. HTTPレスポンス例(成功例) HTTP/1.1 200 OK { “result_code” : 1, “results” : [ { “api_id” : “課金アイテム消費API_01”, “result” : {“result”:”OK”} }, { “api_id” : “アイテム付与API_01”, “result” : {“result”: “OK” } }, { “api_id” : “アイテム取得API_01”, “result” : {“result”: “OK”, {“item_id”:10, “num”:15} } } ] } ※個別のAPI毎の実行結果がリス トで返答される。
- 49. HTTPレスポンス例(失敗例) HTTP/1.1 400 BadRequest { “result_code” : 0, “error” : { “api_id” : “課金アイテム消費API_01”, “err_code” : 1, “msg” : “残金が不足しています。チャージして下さい。” } }
- 50. 利用実績
- 52. 結論
Notes de l'éditeur
- HTTPリクエストの数も減るし一石二鳥
- ALL or Nothing
- ALL or Nothing
- ALL or Nothing