REST API для нескольких потребителей

Question

Например: у нас есть REST API, который предоставляет данные для нескольких потребителей. В большинстве случаев это: интерфейс (доступный для всех), администратор / управление (только для администраторов), мобильное приложение.

Эти данные отличаются данными ответа, которые предоставляет API REST. Например, в запросе администратора API должен ответить на электронное письмо пользователя. На фронтенде нет. Или мобильное приложение не должно получать ненужные данные, которые не отображаются в представлениях.

Моя идея состояла в том, чтобы установить адаптеры перед API REST, но это не сработает, если у вас нет нескольких доступных доменов (например, api.xyz.com, api-manage.xyz.com).

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

Есть ли способ на стороне приложения, например, с промежуточным ПО? Или я знаю, что есть подход, основанный на ролях, но я не думаю, что это достаточно абстрактно, потому что роль не определяет, какое это устройство.

Есть небольшое решение: Решение на основе ролей, какие поля пользователь может получить. Кроме того, потребитель должен указать заголовок или параметр запроса, например «frontend», «admin», «mobile», чтобы определить, какие данные будут возвращены. Это не зависит от того, «на что способен пользователь». Это просто для оптимизации.

Есть ли другие решения?

Answer 1

Ваш API не должен знать о ваших клиентах, но он должен предоставлять клиентам возможность делать то, что они хотят / нуждаются. Допустим, вам нужно отобразить список продуктов с подробностями. На десктопе вы можете принести 100 продуктов, а на мобильных - только 10. Поэтому API должен обеспечивать настраиваемый пейджинг. Также на рабочем столе вы можете получить больше информации, чем на мобильном телефоне. Так что здесь, если у вас есть продукт сущности, на рабочем столе вы получите все поля (например, несколько атрибутов), но для мобильного телефона вы получите только имя и один атрибут (например, цену), чтобы минимизировать размер полезной нагрузки. Поэтому API должен быть универсальным, но предоставлять клиентам возможность использовать его в зависимости от своих потребностей.