Допустим, у меня есть компания, которая оценивает самых симпатичных кошек в Интернете.
Я предлагаю ресурс, на/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 ради примера.
Или что-то подобное.
Для пользователя полезно знать, в каком состоянии находится его учетная запись, и он позволяет вам размещать любую информацию, например, маркетинговое сообщение. Самым важным моментом этого пути является предоставление некоторого легкого наглядного представления вашим пользователям их текущей учетной записи.
Dev
Однако, если ваша аудитория - исключительно разработчики, то я бы сказал: идите с полным HTTP-совместимым способом. Для хранения метаданных вы используете заголовки HTTP.
Вот пример:
Затем предоставьте четкую документацию о том, что означают эти заголовки. Большинство разработчиков сразу перейдут к документации, когда увидят эти пользовательские заголовки, особенно если они видят ограничение. Вы можете пойти еще дальше и показать ссылку в заголовках. Или вы можете показать ссылку на страницу с ценами.
Но опять же, многие разработчики не знают, как работает HTTP.
Так что это ваш звонок
Одно правильнее, другое доступнее.
Разное
Некоторые другие вещи, связанные с вашим вопросом:
источник
UserRole = level1
или как вы хотите называть ее, просто чтобы гарантировать, что потребители всегда знают, как представлять любые данные, которые они получают, и это согласуется во всех ответах, где возвращающиеся модели данных будут отличаться от одного запроса к другому, потребители всегда могут проверить свою роль одинаковым образом.Это зависит от клиента. Обычно вы можете поместить такую информацию в виде гипертекстового сообщения (он же HTML) в тело ответа метода REST. Однако это имеет смысл, только если REST API используется с клиентом HTML.
Аналогично для XML и JSON.
Изменить: вы можете спутать использование API (разверните эту аббревиатуру) с маркетингом ваших типов счетов / пользовательских планов. Я бы не стал смешивать это, так как это всегда становится подозрительным (деловые решения могут потребовать более быстрых изменений, чем изменения в программном обеспечении, чтобы сообщать разные ответы, потому что эти изменения могут вовремя попасть на блюдо).
Вместо этого расскажите своим пользователям через другой канал, например, с помощью бюллетеня, каковы их преимущества.
Это работает особенно хорошо, когда человек, подписывающийся на сервис, не тот, кто программирует против API. Например:
Так что парень, который увлекается программированием, на самом деле это не самый прямой адресат информации.
В качестве альтернативы в ответ на вход в систему и метод информации о пользователе предоставьте все подробности.
Но когда пользователь запрашивает кошек программно, он должен уже знать, почему он возвращает только три кошки или больше. Но вы не решаете эту проблему связи с кодом.
В противном случае разрешите им запросить больше и затем отправьте уведомление об ошибке, если их права не достаточны. Но опять же, это не удобное программное обеспечение.
источник