Как разработать REST API для SaaS с несколькими «компаниями» для одного аккаунта - PullRequest
Новая
       36

Как разработать REST API для SaaS с несколькими «компаниями» для одного аккаунта

0 голосов
/ 28 февраля 2019

В настоящее время я работаю над SaaS для компаний, чтобы управлять их бизнес-данными (сотрудниками, счетами, заказами, продуктами, ...).Текущий дизайн API выглядит следующим образом:

GET /employees?limit=10&offset=0

GET /employees/ID

POST /employees

и т. Д. Для каждой модели.Кроме того, вы можете применить больше фильтров с параметрами запроса.

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

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

Решение 1:

GET /ORGANISATION-ID/employees?limit=10&offset=0

Решение 2:

GET /employees?limit=10&offset=0&organidationId=ORGANISATION-ID

Решение 3:

URI остается тем же, но заголовок установлен: 

|----------------|------------------------|
| Header name    | Value                  |
|----------------|------------------------|
| Authentication | Bearer TOKEN           |
| Organisation   | ID     ORGANISATION-ID |
|     ...        |         ...            |
|----------------|------------------------|

Примечание : Заголовок Authentication всегда установлен.

Лично я считаю, что решение номер 3 является наиболее элегантным, но я не уверен, неуместно ли использовать для этого заголовки.Я думаю, что решение 2 сбивает с толку, и решение 1 заставило бы все конечные точки начинаться с идентификатора организации, что не очень хорошо.

1 Ответ

0 голосов
/ 28 февраля 2019

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

Для меня это означает, что в вашем случае все должно находиться в пространстве имен в организации: 

https://api.example.org/org/[orgid]/employees

Таким образом, для члена нескольких организаций совершенно очевидно, что существует несколько списков сотрудников.

Аналогичным публичным примером может быть github.Все в github - это либо A) пространство имен под пользователем B) пространство имен под организацией, либо C) это конечная точка github верхнего уровня.

...