web-dev-qa-db-ja.com

REST APIはリソースへのアクセス許可を含みます

現在、REST APIがあり、次のようなさまざまなリソースのセットがあります。

GET /cats
GET /cats/{catId}
GET /dogs

クライアントは、リソースのアクセス許可に基づいてアクションを実行できるかどうかを決定します。クライアントが呼び出すものをクエリするには：

GET /cats/{catId}/permissions

また、「deleteCat」、「sellCat」、「initiateCatMating」などのリストを取得するため、読み取り、書き込みなどよりも複雑です。つまり、OPTIONSの呼び出しは機能しません。

これで、クライアントが100匹の猫を例にすると、許可エンドポイントを100回呼び出す必要があります。リソースは関連しているため、許可呼び出しの数は事実上急増し、大きなリストを操作するときにUIの速度が低下します。

次のように、すべてのリソースにアクセス許可を含めるのが良い/許容できる方法かどうかを考えていました。

cat: {
name:string
permissions:[string]
}

このようにして、クライアントは常にリソースで何ができるかを認識します。残念ながら、私はこれに関するガイダンスを見つけることができませんでした。そのため、このアプローチは間違っているか、人々が好きなように実装するだけで、質問をしません。私が見つけたのはいくつかのABAC参照だけでしたが、それは完全に意味がありますが、サーバーがより簡単にアクセスを処理できる方法だけを解決すると思います。クライアントがPOST/cats/{catId}/matingPartner/{cat2Id}を呼び出すことができるかどうかをクライアントに知らせたい。両方の猫の「initiateCatMating」権限。許可されていない場合は、[交配相手を選択]ボタンがUIに表示されません。

ご意見やリンクをお待ちしています。

restapisecuritypermissions
1
Maxim Zabolotskikh

すべてのリソースに権限を含めることは良い/許容できる方法かどうかを考えていました

このようにして、クライアントは常にリソースで何ができるかを認識します。

あなたは本当に近いです。 RESTでは、答えは ハイパーメディアアフォーダンス です。

ウェブについて考えてください。クライアントとして、自分に何ができるかをどのようにして知っていますか？リソースのHTML表現でリンクとフォームを探します（より正確には、汎用クライアントが一連のリンクとフォームをレンダリングします）。なんらかの理由で特定のワークフローに沿って進むことができない場合、そのワークフローに関連するリンクとフォームは表現から削除されます。

（注：これは純粋に「クライアントへの可能性の伝達」です。サーバーは依然として不適切な使用から身を守る必要があります）。

たとえば、ウィキペディアについて考えてみましょう。 https://en.wikipedia.org/wiki/Hypermedia に移動すると、ページの上部に「編集」リンクがあります。これは、「読み取り」リソースから編集をサポートする別のリソースに移動する方法を示しています。編集リソースの下部には大きなハイパーメディアフォームがあり、編集したリクエストを送信する方法を汎用ブラウザに説明しています。

Atom Syndication と Atom Publishing は、リンク関係を定義することで同様の結果を達成します- RDF triple ここにあるものとそこにある何かとの関係を説明します。表現へのリンクを含めることにより、アフォーダンスが利用可能であることをクライアントに知らせます。

cat: {
    name:string
    permissions:[string]
}

独自に開発するのではなく、開発中のJSONハイパーメディア標準を調べたい場合があります。 [〜＃〜] siren [〜＃〜] 、 Hydra など。 Kevin Sookocheff 選択肢の中から選択することについて話し合いましたが、2014年よりも新しいものを探すこともできます。

4
VoiceOfUnreason

Webリンク は、猫のリソースを返し、猫で何ができるかを人々に知らせるときに使用します。たとえば、猫の説明を更新できることを人々に伝えたい場合、GET /cat/1は、関係タイプが「編集」のリンクを返す必要があります。 APIによってリンクが返される方法はコンテンツタイプによって異なります。JSONの場合、JSONスキーマ（ドラフト標準）にはWebリンクの定義があると思います。以下は、atom + xmlの例です。

<link rel="edit" href="http://example.org/media/edit/the_beach.atom" />

クライアントがこのリンクを見ると、ターゲットURIを使用してリソースを編集できることがわかります。 「編集」の意味は、AtomクライアントがターゲットURLにPUTリクエストを送信するプロトコル）で定義されています。

トリックは、ユースケースに一致する標準のリンク関係タイプを見つけることです。標準タイプのリスト here があります。見つからない場合は、ユースケースに合わせて独自の独自のタイプを定義できます。

2
imel96

個別の「許可」リソースは、実際にはRESTにあるものではありません。そのため、おそらくそれについてあまり見ていません。

リソースが受け入れるHTTP動詞を知りたい場合は、OPTIONSリクエストを実行して、「Allow」ヘッダーを確認できます。

たとえば、「weather.com/current_weather」のようなリソースは、クライアントからのPUTまたはDELETEを受け入れず、GETのみを受け入れます。そのことを事前に知る必要がある場合は、現在の天気の計算などをサーバーに行わせずに、OPTIONSリクエストを介してその情報を取得できます。

しかし、最終的にRESTは、「許可を求める」というよりも、「許しを請う」というものです。

つまり、リクエストが機能するかどうかを最初にクライアントで解決するよりも、リクエストを作成して失敗に対処する方が良いということです。

サーバーがリソースをDELETEしたり、リソースを特定の状態にPUTしたりできない場合は、サーバーがその理由を説明します。別のエンドポイントにクエリを実行することはあまり意味がありません。クライアントが元の要求を処理した場合と同じように、クライアントがアクセス許可を持っているかどうかを判断するために、サーバーはおそらく同じ量の作業を行う必要があります。

また、別のリソースに対する以前のリクエストでクライアントに権限を渡すと、リソースが不必要に結合され、権限がサーバーと同期しなくなるリスクもあります。

したがって、要求を行って、失敗を適切に処理するだけです

0
Cormac Mulhall

クライアントがすべてを正しく表示するための情報を必要とする場合、GET /catsは、ご想像のとおり、catリソースで提供する必要があります。

レベル3成熟度 を達成したい場合は、これらの権限をリンクで表すことができます。

GET /cats HTTP/1.1

HTTP/1.1 200 OK
[various headers]

<cats>
  <cat id = "1234" name = "fluffy">
     <link rel = "/linkrels/cat/sellCat" 
           uri = "/cats/1234/sell"/>
  </cat>
  ...
</cats>
0
Ozan