Правильный ответ HATEOAS при создании учетной записи пользователя

Question

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

Они регистрируют учетную запись с данными для входа, затем входят в систему, чтобы получить токен доступа, а затем используют этот токен для доступа к любым конечным точкам, которые не являются register или же login,

Выдача get в корень отвечает каталог с доступными действиями.

Q: Каков правильный ответ от register, чтобы сказать клиенту, что он может делать дальше (т.е. войти в систему)?

1. register технически создает новый ресурс на сервере, поэтому 201 CREATED и Location Заголовок показался бы подходящим. Тем не менее login ссылка не является местоположением вновь созданного ресурса.

2. Должен ли я вернуться 201 Created с Location указывая на вновь созданного пользователя (например, /myaccount или же /users/{id} а затем включить ссылку для входа в тело ответа?

    {
        _links: {
            self: {href: "что здесь происходит?" },
            x:login: { href: "/login" }
        }
    }

3. Я не говорю клиенту вообще, и требую, чтобы они сделали get в корне приложения, чтобы получить список доступных конечных точек. Это должно включать login тем не мение. Предполагая, что клиент должен был сделать это в первую очередь, чтобы получить register ссылка должна быть уже login,

Ожидать, что клиент уже имеет ссылку для входа в систему, неудобно, так как он полагается на предыдущую активность клиента.

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

Answer 1

Мне нравится, когда мой API-интерфейс не отличается от веб-страницы. Если вы хотите, чтобы пользовательским интерфейсом вашего приложения был пользователь, входящий в систему после регистрации, затем 302 из успешного входа в ресурс входа в систему. И при успешном входе в систему 302 отправьте их к соответствующему пункту назначения (т.е., если они попытались получить доступ к чему-либо без токена, затем введите их для входа в систему с пунктом назначения исходного запрошенного ресурса). Это и важная часть вашего # 3. Наличие ссылки в корневом каталоге, ведущей к входу в систему, но вам нужно защитить все остальные ссылки, чтобы они указывали (и ссылались на) имя входа, необходимое для доступа к ресурсу. Клиентское приложение должно ожидать получения ответа на запрос входа в систему в любое время, так как токены могут (и могут) истечь в любое время.

Исходя из этого, возможно, имеет смысл использовать JWT в качестве файла cookie, а не в качестве заголовка авторизации, это облегчит клиенту задачу (ему просто нужно настроить файл cookie).. если клиент скажет родное мобильное приложение, которое поддерживает единую настройку соединения. Если это сервер к серверу, то заголовок аутентификации имеет смысл. Я бы поддержал оба, чтобы охватить оба сценария.

Продолжая идею думать об API как о веб-сайте. Зачем им регистрироваться после регистрации вообще? Почему регистрация аккаунта не заканчивается отправкой токена входа? они просто устанавливают свой пользователь / пароль, зачем заставлять их вводить его снова? Я понимаю, что с некоторыми более экзотическими архитектурами служба регистрации не может выполнить действие входа в систему (возможно, у нее нет закрытого ключа для подписи токена), но если это возможно, я рассмотрю это.

Если вы действительно хотите придерживаться заголовка 201 (что хорошо, просто убедитесь, что документы вашей взаимосвязи регистра указывают на это), то вариант 2 является наиболее близким, на мой взгляд. Заголовок местоположения для URL только что созданной учетной записи 201 является довольно стандартным для создания пользователя. Но я бы не вернул то, что вы предполагали там. Вы как бы возвращаете созданный аккаунт ресурс (вещь со ссылкой для входа), но вам действительно нужен этот пользовательский ресурс? Если вы хотите передать часть сообщений клиенту (например, "Учетная запись создана") на этом ресурсе, тогда, конечно, да, но вы также можете просто вернуть им корневой ресурс.

ТЛ; др; Решите, каким вы хотите, чтобы ваш UX был, а затем заставьте ваш API реализовать ваш UX.