Уровни пользовательских разрешений в RESTful API

Допустим, у меня есть компания, которая оценивает самых симпатичных кошек в Интернете.

Я предлагаю ресурс, на/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}

Я хотел бы сделать это правильно в первый раз, чтобы доставить самых симпатичных кошек в лучшем виде, и мы бы и мы хотели

Я бы сказал, что это зависит от вашей аудитории.

Нет-DEV

Если ваша аудитория не принадлежит разработчикам, я бы пошел следующим образом:

Допустим, вы возвращаете 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!"
    }
}

Или что-то подобное.

Для пользователя полезно знать, в каком состоянии находится его учетная запись, и он позволяет вам размещать любую информацию, например, маркетинговое сообщение. Самым важным моментом этого пути является предоставление некоторого легкого наглядного представления вашим пользователям их текущей учетной записи.

Dev

Однако, если ваша аудитория - исключительно разработчики, то я бы сказал: идите с полным 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. Однако это имеет смысл, только если REST API используется с клиентом HTML.

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

Изменить: вы можете спутать использование API (разверните эту аббревиатуру) с маркетингом ваших типов счетов / пользовательских планов. Я бы не стал смешивать это, так как это всегда становится подозрительным (деловые решения могут потребовать более быстрых изменений, чем изменения в программном обеспечении, чтобы сообщать разные ответы, потому что эти изменения могут вовремя попасть на блюдо).

Вместо этого расскажите своим пользователям через другой канал, например, с помощью бюллетеня, каковы их преимущества.

Это работает особенно хорошо, когда человек, подписывающийся на сервис, не тот, кто программирует против API. Например:

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

Так что парень, который увлекается программированием, на самом деле это не самый прямой адресат информации.

В качестве альтернативы в ответ на вход в систему и метод информации о пользователе предоставьте все подробности.

Но когда пользователь запрашивает кошек программно, он должен уже знать, почему он возвращает только три кошки или больше. Но вы не решаете эту проблему связи с кодом.

В противном случае разрешите им запросить больше и затем отправьте уведомление об ошибке, если их права не достаточны. Но опять же, это не удобное программное обеспечение.