Дизайн REST API: зависимые ресурсы - PullRequest
Новая
       91

Дизайн REST API: зависимые ресурсы

0 голосов
/ 08 мая 2020

У меня есть два ресурса: клиенты и пользователи

У каждого клиента может быть несколько пользователей. Пользователи существуют только внутри клиента.

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

Пример: Клиент имя, пароль пользователя, адрес электронной почты пользователя

Я хочу создать этого клиента и этого пользователя в Rest API. Как мне выполнить процедуру?

Моя первая мысль была: 

POST /customer
body: {name: foo}
return {customer resource}

, а затем: 

POST /customer/{id}/user
{email: user@email.com, password: secret}
return {user resource}

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

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

POST /account
{customer_name: foo, user_email: user@email.com, user_password: secret}
return {user resource}

Что-нибудь из этого имеет смысл? Другие идеи?

1 Ответ

0 голосов
/ 08 мая 2020

Я хочу создать этого клиента и этого пользователя в Rest API. Как мне выполнить процедуру?

Подумайте, как бы вы это сделали в Интернете.

У вас, вероятно, будет какая-то страница регистрации, ресурс, который будет включать представление Форма. Элементы управления вводом формы будут описывать посетителю желаемую информацию. Когда посетитель нажимает кнопку отправки, браузер создает HTTP-запрос, согласованный с сервером обработки форм HTML, и отправляет этот запрос обратно на сервер. Сервер считывает информацию из полезной нагрузки сообщения, выполняет свою работу и отправляет обратно клиенту другую веб-страницу со статусом, дополнительной информацией, ссылками на другие интересные ресурсы и т. Д.

Для части протокол взаимодействия, который является небезопасным (это означает, что семантика запроса не является эффективно только для чтения), как, вероятно, "подписка", форма будет указывать, что токен метода POST будет использоваться в запросе - строка HTTP-запроса.

Целевым URI может быть что угодно - браузер просто скопирует любую форму form.action, заданную сервером. 

POST /c4b809c9-2106-4664-8149-5d1817ca4e4b

было бы прекрасно выбор (хотя это может разочаровать операторов, которые пытаются выяснить, что происходит, просматривая журналы HTTP). . Так что это может быть более знакомо 

POST /signups

Вы можете создать дополнительные ресурсы (да, более одного) при обработке запроса POST; таким образом, ваш обработчик POST регистрации может создавать ресурсы для клиента и пользователя.

Каждый из этих ресурсов будет иметь свой собственный URI. 

/companies/1
/users/3

Это было бы хорошо. С механической точки зрения может быть преимущество использования общего стержня для обоих. Опять же, подсказки semanti c в журналах могут помочь операторам в их расследованиях. Кроме того, если два URI имеют одинаковый root, вы можете использовать точечные сегменты, чтобы ссылаться на один ресурс из другого в более общем виде 

<base href="/companies/1/users/3">
<a href="./4">/companies/1/users/4</a>
<img src="../images/logo.gif" alt="/companies/1/images/logo.gif">
...