GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて - 余白
DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう
脱RESTful API設計の提案
3. フロントアプリ スタンドアロンゲームの構成要素(例) グラフィック アニメーション サウンド レベルアップ戦闘ルール 評価・報酬 シナリオ ゲームシステム・基本ルール 演出 セーブ・ロード 全ての機能はフロントアプリに実装される 4. ソーシャルゲームになって構成要素が増えた 各種 マスタリソース 追加シナリオ イベント配信 アカウント 引き継ぎ 会員登録 多端末 同時利用 運営から アカウント凍結 アプリ上データ アカウント関連機能 会員 セーブデータ データ管理機能 各種ログ管理 フレンド 登録管理 （準）課金機能 その他運営機能 連続ログイン 報酬 課金管理 アイテム ガチャ管理フレンド連携 報酬管理 報酬付与 グラフィック アニメーション サウンド レベルアップ戦闘ルール 評価・報酬 シナリオ ゲームシステム・基本ルール 演出 セーブ・ロード どの機能をゲームサーバに持たせる
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
RESTful API の設計のキホン
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
