4

新しい Web ベースのアプリケーションに REST ベースのアーキテクチャを選択しました。プラットフォーム全体が RESTful サービスの形式で公開されているため、これらの上に任意の UI (WEB/モバイル) を構築できます。したがって、アプリケーションは 3 つの層、DB、アプリケーション層 (これは RESTful サービスを公開するだけです)、および UI (現在は Web サービスを使用する HTML5/CSS/Javascript ベースの UI) にあります。

このアプリケーションには役割ベースのアクセスもあるため、役割に基づいて UI を設計する必要があります。Web サービスがサービス応答で一連の特権を返し、それを Javascript で使用して UI を構築することは良い考えですか?

ロールの UI のバリエーションは次のとおりです。
メイン メニューはロールに基づいて変更される可能性があります
タブはロールに基づいて制御
する必要があります アプリケーションのほとんどのページはウィジェット ベースであり、ウィジェットの表示は再びロールにタグ付けされます

繰り返しますが、これが正しいアイデアであるかどうかを知りたいです。提案してください。

4

2 に答える 2

2

HATEOAS (Hypermedia As The Engine Of Application State) 制約に従うには、どのナビゲーション、タブに関する特定のロジックを含む「アプリケーション状態」に対して有効な状態遷移 (リンクなど) を REST サービス自体で提供する必要があります。などは、ユーザーの役割に基づいて使用できます。

そのため、リソースは、ログインしているユーザーに固有の結果を返すことができるように設計する必要があります。

例 ( HALをハイパーメディア タイプとして使用)

GET /users/123/navigation

{
  "_links": {
    "http://api.service.com/rels/home": { "href"="/" "title"="Home" },
    "http://api.service.com/rels/admin": { "href"="/admin" "title"="Admin" }
   }
}

そうすることで、「どのロールが何を実行できるか」というビジネス ロジックがservice内に保持されます。これは、そのロジックが実際に属する場所です。

于 2012-06-08T12:02:29.557 に答える
0

そのためには、すべてのメニューオプション、ウィジェット、およびページ名をデータベースに保存し、実行時にメニューをロードする必要があります（つまり、最初のリクエストはロールの送信とサーバーからの getMnu です）。

ロールベースの Rest アーキテクチャを簡単に作成し、Restful サービスにセキュリティを提供することもできます。

于 2012-06-08T11:44:45.290 に答える