Рівні дозволів користувачів у API RESTful

Скажімо, у мене є компанія, яка займає рейтинг симпатичних котів в Інтернеті.

Я пропоную ресурс, на/cats/ якому користувачі надають останнім, милим чарівним котам.

Користувачі можуть отримати лише 3 найкращих котів, якщо вони взагалі не заплатили або зареєструвались. Топ-10 котів, якщо вони заплатили 337 доларів і ввійшли в систему, і перші 100 котів, якщо вони заплатили 1337 доларів і ввійшли в систему. У мене є "ідентифікатор користувача" під час подання запиту.

Коротше кажучи, споживачі /cats/отримують різну кількість котів, виходячи з рейтингу користувачів . У мене є ідентифікатор користувача на споживчому кінці, але я не маю явного представлення рівня користувача на споживчому кінці. Хочу повідомити користувачів, що вони можуть оновити свою підписку під час подання запиту. Тобто мені потрібно розрізняти 3 котів, оскільки я пропоную лише 3 котів та 3 котів, тому що це дозволив рівень користувача .

Яка найкраща практика розмежування обмеження ресурсу, оскільки споживач не має достатніх привілеїв та його обмеження, тому що саме це має споживач?

Як клієнт знає, чи зможе оновити свій рейтинг? Тобто вони отримали лише обмежений ресурс, оскільки вони не мають дозволів. Яка тут найкраща практика?

Зауважте, це грубе спрощення фактичного випадку. Крім того, просто для уточнення - читання цінується.

Оновлення:

Ось варіанти, які ми розглянули:

• Зберігання об’єктів дозволів користувача один раз на клієнті, запит на нього лише тоді, коли здійснюється вхід або оновлення облікового запису.
• Передача nullзначень у JSON, що вказує на те, що вони існують, але фактично нічого не передано. Тож 10 котів для користувача з 3 кішками могли бути["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.

Так що це ваш дзвінок

Одне правильніше, інше - доступніше.

Різне

Деякі інші речі, пов'язані з вашим запитанням:

• Не забувайте про 429 Занадто багато запитів .
• Не забувайте про заголовок відповіді WWW-Authenticate .

Як клієнт знає, чи зможе оновити свій рейтинг?

Це залежить від клієнта. Зазвичай ви можете розмістити таку інформацію у формі повідомлення про гіпертекст (він же HTML) у тіло відповіді методу REST. Однак це має сенс лише в тому випадку, якщо API REST використовується з клієнтом HTML.

Аналогічно для XML та JSON.

Редагувати: Ви можете переплутати використання API (розгорніть цю абревіатуру) з маркетингом типів своїх облікових записів / планів користувачів. Я б не змішував це, оскільки це завжди стає рибним (бізнес-рішення можуть вимагати швидших змін, ніж зміни в програмному забезпеченні для передачі різних відповідей через те, що ці зміни можуть вчасно потрапити на блюдо).

Натомість повідомте своїм користувачам через інший канал, наприклад, з інформаційного бюлетеня, які їх переваги.

Це особливо добре спрацьовує, коли людина, яка підписується на сервіс, не є тим, хто програмує проти API. Наприклад:

Джордж (який з 36 років люблячих кошенят - гордий хлопець) купує доступ до cute-cats-4-me.com і повідомляє своєму 16-річному подружжю (який добре працює з написанням комп'ютерних систем, включаючи Linux), щоб створити додаток для цифрових вивісок із зображенням симпатичних маленьких кошенят мило на стіні в квартирі.

Тож хлопець, який із задоволенням програмує це, насправді не є самим прямим адресатом інформації.

Крім того, у відповідь на логін та метод користувальницької інформації вкажіть усі деталі.

Але коли користувач запрошує кішок програмно, вона повинна вже знати, чому вона отримує лише трьох котів назад або більше. Але ви не вирішите цю проблему зв'язку з кодом.

В іншому випадку дозвольте їм запитувати більше, а потім надішліть попередження про помилку, якщо їх прав недостатньо. Але знову ж таки, це не зручне для користувача програмне забезпечення.