language-agnostic - どのレイヤーにRESTAPIを配置していますか？

Question

私たちのアプリケーションは次のように構成されています。

UI <-> RESTAPI<->ワークフロー<->ビジネスロジック<->DAL<-> DB

しかし、私は人々がやっているように見えるいくつかの例を見ています

UI<->ワークフロー<->RESTAPI<->ビジネスロジック<->DAL<-> DB

これは私の想像ですか？または、2番目のオプションは実行可能な代替案と見なされますか？

Answer 1

それは実際には、ワークフローの意味に関連しています。

アプリケーション状態のエンジンとしてのハイパーメディアは、状態/リソースの有向グラフを提供します。これらのグラフがワークフローを形成する必要はありません (たとえば、特定の開始点と終了点を持つ)。それらはサイクルを形成し、双方向リンクなどを持っている可能性があります。このグラフは、何らかの形でビジネス ロジックから派生したものだと思います。

UI にワークフロー (グラフを介したあるポイントから別のポイントへの特定のパス) を含めると、REST API についていくつかの仮定を立てることになり、その結果、UI とビジネス ロジックが緊密に結合され、REST の発見可能性が失われます。

一般に、ワークフロー (命令型プログラミング) と REST (宣言型プログラミング) を混在させることは非常に問題があります。最適なアプローチは、ユーザーが事前に定義されたオーダーメイドのワークフローによって状態を制約するのではなく、状態のネットワークをナビゲートできる適応型 UI を用意することです。とにかく、それがブラウザの仕組みです。

ただし、いくつかのワークフローが本当に必要な場合は、相互接続されたリソースのチェーンを作成し、ユーザーを最初のリソースに誘導することで実装できます。この意味で、最初のオプションは有効ですが、ビジネス ロジックとワークフローの分離はグレー エリアであることがわかります。ワークフローはビジネス ロジックの一部であり、より適切に言えば、ビジネス ロジックから派生したものです。

これらの意見は私自身のものですが、このトピックに関する優れた関連記事は次の場所にあります: http://www.infoq.com/articles/webber-rest-workflow

Answer 2

私は ReST が実際に現在どのようなものであるかにさらされているところです。ここでベースから外れていないことを願っていますが、私が理解しているように、クライアントはどの状態 (ワークフロー) に転送するかを選択する責任があるため、#2 だと思います。間違いなく有効です。実際、ReST API でワークフローをどのように実装しているか知りたいです。

Answer 3

REST はリソースへのアクセスです。問題は「資源とは何か」です。ほとんどの回答は、それはかなり低レベルの情報だというものです。

複合アプリケーションまたはワークフローは、1 つ以上のリソースに依存します。

リソースがワークフローに依存しているとは言い難いです。不可能ではありません。しかし難しい。

RESTful インターフェイスを設計するときは、CRUD ルールしか利用できません。最も一般的な期待は、レスポンスがリクエストと完全に一致していることです。X を POST するとき、唯一の状態変更は新しい X を作成することであると想定します。オプションの Z のペアで X と Y を作成しないでください。

2 番目の選択肢として、REST をより適切なコンテキスト (ステートフル オブジェクトへのアクセス) に置くことをお勧めします。