REST API-モバイル固有の課題

モバイル側で、新しいiOSアプリプロジェクトに取り組んでいます。いくつかのアーキテクチャの変更が行われているため、構築中のアプリやWebサイトなどの他のクライアントが使用するカスタムビルドのプライベートAPIに依存する必要があります。

設計されているAPIは、HTTP動詞にマップされるリソース中心のURIおよびCRUD操作のRestスタイルに従います。次のようなもの：

GET www.example.com/books
DELETE www.example.com/books/482094
POST www.example.com/users/6793

問題は、このスタイルでは、多くの場合、モバイルクライアントが単一のアプリ画面の読み込みや単一のユーザーUIアクションの管理を行う必要が生じることです。これにより、必要なものがすべて揃うまで、アプリは8秒間ロードモードになります。低速で応答しないアプリ。

接続に関しては、モバイルクライアントには重大な制限があるため、理想的には次のようなルールに従う必要があります。

1画面== 1 API呼び出し

1保存== 1 API呼び出し。

これにより、REST設計の原則との衝突コースに入る多くの状況があります。例：

• アプリが1日間オフラインで、バックエンドデータベースの4つのテーブルと同期する必要があり、次のような呼び出しが必要だとします www.example.com/sync_everything?since=2015-07-24
• ユーザーが自分のオブジェクトの多くを編集できる画面があるとしましょう。たとえば、todoリストでタスクをチェックします。編集ごとに1つのAPI呼び出しを行うのではなく、1つのバッチAPI呼び出しですべてのタスクレコードを編集する方法が必要です。
• ORDER、SALESMEN、およびPRODUCT dbテーブルからの情報を混合する画面があるとしましょう。3つではなく1つの呼び出しでそのデータを取得する必要があります。

リスクは、最も安らかなAPIが存在し、また、最も役に立たない無反応のモバイルアプリが存在する可能性があることです。

問題は、私はただの新しい請負業者であり、私が必要なのは、私がそれらのポイントを作るのに役立つもの、尊敬される情報源からの記事、またはそのようなものです。モバイルクライアントのRESTスタイルで妥協している主要なプレーヤー（例：複合集計APIエンドポイントの使用による）。

または、この一般的な問題の解決策。ありがとう！

設計されているAPIは、HTTP動詞にマップされるリソース中心のURIおよびCRUD操作のRestスタイルに従います。

これがあなたの問題です。

データベース内のモデルにリソースを制限しました（と仮定しています）。サーバーにはデータベースに表現のないリソースの概念がないため、これらすべてのリソースをロードするには時間がかかります。

たとえば

www.example.com/books/482094
www.example.com/books/582045
www.example.com/books/427454
www.example.com/books/319343

ライブラリを取得するためにすべてをロードする必要がある

これはRESTfulなデザインの問題ではなく、これは実際のRESTアンチパターンです。RESTには、データベースモデルを含むシステムの他のリソースとの1対1のマッピングがリソースに必要であると言う絶対的なものはありません。

解決策は、ロードするものによりよく一致するリソースをさらに作成することです。常に一緒になる5つのリソースがある場合、それらの5つのリソースの情報を含む新しいリソースを作成します。

あなたが持っているべきものはこのようなものです

www.example.com/users/334/my_library

そのユーザーのすべての書籍が読み込まれます。「my_library」はデータベースのモデルではありませんが、リソースです。サーバーはデータベース内のモデルに基づいて作成しますが、1対1のマッピングはなく、サーバーはDBモデルを変更せずにこのリソースを作成する柔軟性を備えています。

あなたも持っているかもしれません

www.example.com/users/334/favioured_books
www.example.com/users/334/books_ordered_last_week
www.example.com/users/334/wishlist

データベースまたはドメイン空間にモデルとして存在する必要はありません。

Railsのようなフレームワークは、リソースを1対1の方法でドメイン空間のモデルにデータベースの行と1対1で再びマップするように人々に教えたため、これは間違ったことだと誤解されています。これは必要ではなく、推奨されません。

リソースは多数、安価で軽量でなければなりません。それらは簡単に作成でき、ドメインモデルから抽象化する必要があります。新しいものが必要な場合は、新しいものを作成してください。それを実行するのに問題がある場合、それはRESTの障害ではなくフレームワークの障害です。

もちろん、フレームワークでこれを行うことができるかどうかは、もちろん大きな問題です。「時間を節約する」ために1対1をマップするコースを取っているRailsやDjangoのようなフレームワークは、これを行うのを難しくしています。しかし、それはフレームワークの欠陥であり、RESTfulな設計の欠陥ではありません。

これは、Jim Webberがこれについてより詳細に議論している（Railsのいくつかの掘り下げも含む！）

https://yow.eventer.com/yow-2011-1004/domain-driven-design-for-restful-systems-by-jim-webber-1047