RESTful дизайн для доступа к одному и тому же ресурсу в разных форматах из разных аудиторий - PullRequest
Новая
       5

RESTful дизайн для доступа к одному и тому же ресурсу в разных форматах из разных аудиторий

2 голосов
/ 04 февраля 2020

Вариант использования

Я создаю интернет-магазин, где люди могут зарегистрироваться / войти в систему и приобрести (а затем управлять) своими лицензиями SaaS. Для этого я создал (среди прочего) следующие конечные точки REST: 

// Lists all licenses which are linked to this user
r.Get("/users/{userID}/licenses", api.LicenseSvc.HandleGetLicenses())

// List details (such as purchase date, seat information, ...) for a given licenseID
r.Get("/users/{userID}/licenses/{licenseID}", api.LicenseSvc.HandleGetLicense())

// Creates a new license for the signed in user
r.Post("/users/{userID}/licenses", api.LicenseSvc.HandleCreateLicense())

// Each license has a limited number of seats. The license manager can free up seats to make room for others
r.Delete("/users/{userID}/licenses/{licenseID}/seats/{seatID}", api.LicenseSvc.HandleDeleteSeat())

Указанные выше конечные точки должны использоваться только в панели управления интернет-магазином / лицензиями. В то же время одна и та же служба должна обслуживать конечные точки для продуктов SaaS, которые фактически используют лицензии, которые пользователь создал / приобрел ранее. Для этого продукта SaaS требуются разные конечные точки, такие как:

  • Конечная точка для проверки при запуске, является ли данная лицензия действительной для всех
  • Конечная точка, которая также получает лицензию по идентификатору (см. Выше). ), но он должен возвращать только часть ресурса лицензии (например, он не должен возвращать дату покупки лицензии)

Мой вопрос

Из-за того, что я создаю один REST API, который используется двумя разными «аудиториями» (с одной стороны, менеджер лицензий / клиент, а с другой - программное обеспечение SaaS), я чувствую, что сталкиваюсь с конфликтами.

Аутентификация обеих аудиторий различна, обе аудитории хотят получить доступ к одному и тому же виду ресурса (например, лицензии), но «формат» ресурса (нет данных, чувствительных к клиенту для запрашивающей стороны SaaS) должен отличаться в зависимости от аудитория.

  1. Должно ли это отражаться в различных URL-адресах REST или я должен обрабатывать все эти логи c внутри моего маршрута e обработчики?
  2. Должен ли я даже создать два разных сервиса, обслуживающих эти разные аудитории? Как один API для панели пользователя / управления лицензиями и один для продуктов SaaS!?

1 Ответ

1 голос
/ 04 февраля 2020

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

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

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

...