REST APIを使用したサーバーとクライアントの分離

Question

Webアプリケーションをサーバー側コンポーネントとクライアント側コンポーネントに完全に分離する方法を考えていました。別々のサーバーで両方のコンポーネントをホストできる範囲でアプリを分離したいと思います。

したがって、たとえば、次のようになります。

サーバー1（APIサーバー）：HerokuやEC2などのDjangoで実行されるサーバー側コンポーネント。
サーバー2（静的サーバー）：S3やCloudFrontなどの静的サーバーのAngularJSで実行されるクライアント側コンポーネント。

これらのコンポーネント間の通信は、JSON REST APIを使用して行われます。

質問：

このアプローチは一般的ですか？お勧めですか？

FacebookやTwitterなどの企業はほとんど、モバイルアプリやオープンAPIと同じAPIをWebアプリに利用していますか？
ログインプロセスにoAuth2を使用することは良い考えですか？

したがって、ユーザーはサーバー1（これはサーバー1の唯一のページです）のログインページにリダイレクトされ、認証が成功した場合はトークンを使用してサーバー2にリダイレクトされます。これは最善のアプローチですか？これをやると、「流れを壊す」みたいな感じがします。これは正常ですか？

これの動機は、私のWeb、iOS、およびAndroidクライアントに同じAPIを使用できるようにすることです。

ありがとう！

Rob · Answer

JSON/HTTPは本当に優れた分離メカニズムであり、さらに疎結合にするためのいくつかの提案をします。

JSON/HTTPインターフェースの業界での急速な採用は、人々がそのモデルの有用性をどのように捉えているかをよく物語っています。

MUST IGNOREルールを適用します。

つまり、JSON（クライアントまたはサーバー）を解析する場合、アプリは認識できないフィールドを無視する必要があります。

XMLは、アプリが各フィールドを理解する必要があるか、そうでなければドキュメントが無効であるという考えを取り入れました。しかし、ほとんどすべての変更により、クライアントはサーバーがアップグレードするたびにアップグレードする必要があったため、バージョン管理に問題が発生しました。情報フィールドを追加することでさえ、仕様に違反しました。 MUST IGNOREを使用すると、サーバーは他のフィールドの意味を削除または変更しない限り、いつでも新しいフィールドを追加できます（以下を参照）。既存のクライアントは新しいフィールドを無視できます。むしろ、それらは新しいフィールドを無視しなければなりません。

「MUST IGNORE」および「MUST UNDERSTAND」を検索すると、そのことについて述べている多くの優れた記事が明らかになります。

重大な変更を最小限に抑えます。

「重大な変更」とは、既存のクライアントを壊す変更です。つまり、クライアントが使用するフィールドを削除します。またはフィールドの意味を変更する（つまり、金額フィールドをドルから円に変更する）。つまり、現在使用しているデータに関するクライアントの想定を無効にするものです。

重大な変更により、すべてのクライアントは、新しいセマンティクスをサポートするか、欠落しているフィールドへの依存をやめるように変更を加える必要があります。必要な場合以外は、行わないでください。

次の論理的なステップは一種の論争になります-しかし極端な場合はneverに重大な変更を加えます。つまり、すべてのリリースに対して完全な下位互換性があります。それは現実的かもしれませんし、そうでないかもしれません。また、初期のバージョンから手荷物を運ぶ必要があるかもしれませんが、クライアントのための多くのチャーンを節約します。

OAuth 2は、よく考えられ、標準化されたセキュリティプロトコルにとって本当に良い策です。どの妥協案がOKかによっては、座ってもっとシンプルなものを設計することもできます。しかし、OAuthは、何年にもわたって業界で精査されてきた優れたプロトコルであるため、多くの時間をかけて問題を解決してきました。また、標準ライブラリは、クライアントとサーバー。私はOAuthプラグインをDjangoに1つのプロジェクトで使用しましたが、それは本当にうまくいきました。
JSONパーサーは広く普及しているため、クライアントに関係なくsingle APIを維持すると、作業がはるかに簡単になります。うまくいかない場合もあります-場合によっては、クライアントはXMLまたは独自のプロトコルのみを理解できますが、単純なものから始めて複雑さを追加することで生活が楽になります。

stormlifter · Answer

これは非常に一般的であり、モバイルアプリを設計するときに役立ちます。アプリケーションは、html /ビジュアルレイヤーがアタッチされたデータの生成に重点が置かれるのではなく、すでに「リソース指向」であるためです。

Djangoの側は http://Django-rest-framework.org/ をお勧めします。私は毎日貢献しており、毎日使用しています。 Djangoの上のビルディングブロックは、分離を簡単かつ強力にします。

OAuthについては、する必要はありません。そのWebサイトを確認すると、APIでoAuthを設定する方法も示されます。デフォルトでは、ユーザー名/パスワード認証を簡単に使用できます。angularアプリはユーザー名とパスワードの組み合わせをエンドポイントに送信し、エンドポイントに「トークン」で応答します。アプリが適切なTLSを使用してホストされている限り（）トークンは安全です。メソッドを簡単に追加できますトークンを更新してセキュリティを強化します。