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

23

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

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

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

Бенджамин Грюнбаум
источник
4
Теперь я хочу увидеть фотографии милых кошек
Кэрри Кендалл,
Я не понимаю Если вы нигде не храните «пользовательский уровень», вы не сможете различить. Похоже, что у вас нет никакой пользовательской информации, хранящейся на сервере, поэтому вы не можете сохранить ее пользовательский уровень вместе с ней.
Ян Догген
@JanDoggen У меня есть уровень пользователя на сервере (клиент передает идентификатор на сервер).
Бенджамин Грюнбаум
Помогите? Я не получаю ссылку 1337?
Марьян Венема
Leet
JustinC

Ответы:

18

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

Нет-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.

Так что это ваш звонок

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

Разное

Некоторые другие вещи, связанные с вашим вопросом:

Флориан Маргейн
источник
1
Да, это имеет абсолютный смысл, хотя в качестве примечания я нахожу, что некоторая информация об аутентификации (ent / orize), помещаемая в заголовки HTTP, является подходящим подходом, поскольку это фактически метаданные.
Джимми Хоффа
@JimmyHoffa Это действительно метаданные, и моей первой мыслью было использование заголовков HTTP. Однако в этом случае HTTP-заголовки не обеспечивают достаточной видимости для клиента и степени детализации, необходимой для маркетинговых сообщений. (Отредактировал ответ, чтобы добавить эту деталь.)
Florian Margaine
@JimmyHoffa как? 402 не пойдет в этом случае. Что ты посоветуешь?
Бенджамин Грюнбаум
@ BenjaminGruenbaum Я не сказал коды ответа, я сказал заголовки; Вы можете добавить все пользовательские заголовки, которые вы хотите для метаданных, было бы целесообразно, чтобы все ответы от успокоительного API-интерфейса просто имели роль пользователей в заголовке как UserRole = level1или как вы хотите называть ее, просто чтобы гарантировать, что потребители всегда знают, как представлять любые данные, которые они получают, и это согласуется во всех ответах, где возвращающиеся модели данных будут отличаться от одного запроса к другому, потребители всегда могут проверить свою роль одинаковым образом.
Джимми Хоффа
1
@ BenjaminGruenbaum Я полностью переписал ответ.
Флориан Маргэйн
4

Как клиент узнает, могут ли они повысить свой рейтинг?

Это зависит от клиента. Обычно вы можете поместить такую ​​информацию в виде гипертекстового сообщения (он же HTML) в тело ответа метода REST. Однако это имеет смысл, только если REST API используется с клиентом HTML.

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


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

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

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

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

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

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

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

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

hakre
источник
1
@Racheet: У вас есть проблема, когда у девочек есть деньги в доме и они говорят мальчикам, что делать?
Хакре
1
У меня есть проблема с примером, который утверждает, что девушкам нужны парни, чтобы они программировали для них.
Рашит