RESTful APIのユーザー権限のレベル

インターネットで一番かわいい猫をランク付けしている会社があるとしましょう。

/cats/ユーザーに最新のかわいい猫を提供するリソースを提供します。

ユーザーは、支払いを行っていないか登録していない場合、上位3匹の猫のみを取得できます。337ドルを支払ってログインしている場合は上位10匹の猫、1337ドルを支払ってログインしている場合は上位100匹の猫。リクエストを行うときに「ユーザーID」があります。

要するに、消費者は/cats/「ユーザーランキング」に基づいて異なる数の猫を取得します。消費側にはユーザー識別子がありますが、消費側にはユーザーレベルの明示的な表現はありません。リクエストを行うときにサブスクリプションをアップグレードできることをユーザーに通知したいと思います。つまり、3匹の猫と3匹の猫しか提供していないため、3匹の猫を区別する必要があります。これは、ユーザーレベルで許可されているためです。

消費者が十分な特権を持っていないためにリソースを制限し、それが制限されていることを区別するためのベストプラクティスは何ですか？

クライアントは、ランキングをアップグレードできるかどうかをどのように知っていますか？それはので、彼らは限られたリソースを持っている彼らは権限がありません。ここでのベストプラクティスは何ですか？

これは実際のケースを大幅に単純化したものであることに注意してください。また、単に明確にするために-読んでいただければ幸いです。

更新：

検討したオプションは次のとおりです。

• クライアントに一度ユーザー権限オブジェクトを保存し、アカウントのログインまたはアップグレードが実行されたときにのみ照会します。
• null存在することを示す値をJSONで渡しますが、実際には何も転送されませんでした。したがって、3匹の猫を持つユーザーの場合、10匹の猫は["Garfield","Sylvester","Puss in Boots",null*7]
• リソース許可ペアを渡す {cats:["Whiskers","Fluffy","Socks"],authCount:3}

一番かわいい猫を可能な限り最良の方法で配達するために、初めてこれを正しく行いたいと思います。

聴衆次第だと思います。

開発者なし

あなたの聴衆が開発者のものでないならば、私は次の方法で行きます：

例のためにJSONを返すとします。

GET /cats HTTP/1.1

{
    "cats": [
        "Can I haz cheeseburger",
        "If it fits, I sits",
        "It's caturday!"
    ],
    "permissions": {
        "level": "free",
        "information": "You have access to 3 cats. Upgrade to ... to get 10 cats!"
    }
}

または似たようなもの。

ユーザーが自分のアカウントのステータスを知ることは有益であり、マーケティングメッセージなど、必要な情報を入力できます。この方法の最も重要なポイントは、現在のアカウントのユーザーに簡単に見えるようにすることです。

開発

しかし、もしあなたの聴衆が純粋に開発者なら、私は言うでしょう：完全なHTTP準拠の方法で行ってください。メタデータを保存するには、HTTPヘッダーを使用します。

以下に例を示します。

GET /cats HTTP/1.1

X-Account: anonymous
X-Account-Possible-Upgrades: 2
X-Account-Limit: 3

次に、これらのヘッダーの意味を明確に文書化します。ほとんどの開発者は、これらのカスタムヘッダーが表示された場合、特に制限が表示されている場合は特に、ドキュメントに直接アクセスします。さらに進んで、ヘッダーにリンクを表示できます。または、価格設定ページへのリンクを表示できます。

X-Account-Doc: http://your/doc

しかし、繰り返しますが、多くの開発者はHTTPの仕組みを知りません。

それはあなたの電話です

1つはより正確で、もう1つはよりアクセスしやすいです。

その他

あなたの質問に関連する他のいくつかのその他のもの：

• 429についてのリクエストを忘れないでください。
• WWW-Authenticate応答ヘッダーを忘れないでください。

クライアントは、ランキングをアップグレードできるかどうかをどのように知っていますか？

それはクライアントに依存します。通常、このような情報をハイパーテキストメッセージ（HTML）の形式でRESTメソッドの応答本文に入れることができます。ただし、REST APIがHTMLクライアントで使用される場合にのみ意味があります。

XMLおよびJSONでも同様です。

編集： API（この頭字語を展開）の使用とアカウントタイプ/ユーザープランのマーケティングを混同する可能性があります。私はこれを混同することはありません、常に怪しげです（ビジネス上の決定は、これらの変更が時間内に大皿に乗ることができるため、異なる応答を伝えるためにソフトウェアの変更よりも速い変更を必要とするかもしれません）。

代わりに、ニュースレターなどの利点を別のチャネルでユーザーに伝えてください。

これは、サービスにサインアップしている人がAPIに対してプログラミングしている人ではない場合に特にうまく機能します。例えば：

ジョージ（36歳の子猫を誇らしげに同性愛者である）は、cute-cats-4-me.comへのアクセスを購入し、16歳の配偶者（Linuxを含むコンピューターシステムのスクリプト作成に長けている）に、アパートの壁に素敵な小さなかわいい子猫を表示するデジタルサイネージアプリケーション。

プログラミングを楽しんでいる人は、実際にはそれほど単純な情報の宛先ではありません。

または、ログインおよびユーザー情報メソッドへの応答として、すべての詳細を提供します。

しかし、ユーザーがプログラムで猫をリクエストする場合、3匹以上の猫しか返さない理由をすでに知っている必要があります。ただし、この通信の問題をコードで解決するわけではありません。

それ以外の場合は、より多くのクエリを許可し、権限が十分でない場合は失敗通知を返します。しかし、これもユーザーフレンドリーなソフトウェアではありません。