7

REST API(HATEOAS) がある場合hypermedia-drivenは、応答にリンクを含めたり省略したりすることで、クライアントの動作を簡単に変更できます ( _links)。これにより、クライアントは、の現在の状態で可能な操作のアクセス許可をテストすることを完全に忘れることができますresource(操作へのリンクが存在するかどうか)。

さらに、現在のユーザーがプロパティを表示する権限を持っていない場合は、応答でプロパティを除外できます。

このようにして、承認は完全にサーバー上で行われます (そして、実行/表示できるアクションとプロパティを制御します)。

read-onlyしかし、財産を持ちたい場合はどうすればよいでしょうか? REST APIプロパティがリクエストに存在する場合 ( _POST_OR )、プロパティを無視しても問題ありません_PUT_。保存されないだけです。しかし、クライアントが書き込み専用プロパティと読み取り専用プロパティを区別して、ユーザーに適切なコントロールを表示するにはどうすればよいでしょうか (たとえば、無効な入力フィールドHTML)。

目標は、ユーザーのアクセス許可を決して持たないようにすることですclient requestが、完全にリソース主導型にすることclient/frontendです。

どんな助けでも大歓迎です:-)

4

1 に答える 1

1

私があなたの質問を誤解した場合は、前もってお詫び申し上げます。と言う事で…

しかし、クライアントは書き込みと読み取り専用のプロパティをどのように区別して、ユーザーに適切なコントロールを提示できますか (HTML で無効になっている入力フィールドなど)。

さて、これには複数の解決策があります。私が個人的に考えることができる最も単純なものは、各プロパティを次のような単純な構造を持つオブジェクトにすることです。

    ...

    someProperty: {
        value: 'some value',
        access: 'read-only'
    },
    someOtherProperty: {
        value: 'some value',
        access: 'write'
    }
    ...

accessプロパティの「アクセス」レベルを表現する方法（列挙型、ブール値、 beへの変更など）を使用して、必要に応じて創造的になることができますisReadOnly。

その後、API を使用している人は、自分が読み取り専用かどうかを知ることができます。POST ペイロードの一部として「読み取り専用」プロパティの「書き込み」値を送信すると、403 応答以外は期待できません。

編集:この方法でプロパティを変更できない場合でも、これを達成できる他の方法がいくつかあります。

  • 各プロパティが持つアクセス権を説明するドキュメントを書く
  • 各プロパティのアクセス レベルを示す応答を受け取るために、ユーザーが 1 つ以上のプロパティを送信できるルートを作成します (応答: { propName: 'read-only'、propName2: 'write' など)。
  • 応答の一部として propertyAccess マップを返します (プロパティをアクセス レベルにマッピングします)。

結局のところ、プロパティをアクセス レベルにマップする方法が必要なだけです。ただし、それが行われるかどうかは、API に対する制限と要件、加えられる変更、およびクライアントとビジネス要件の両方に受け入れられるものによって異なります。

于 2015-07-25T19:01:02.083 に答える