json - 创建用户帐户时正确的 HATEOAS 响应

Question

我有一个在使用 HATEOAS 的 Node 中编写的 REST api。用户需要拥有一个帐户才能访问大部分内容。

他们使用登录详细信息注册帐户，然后登录以获取访问 token ，然后使用该 token 访问任何未注册或登录的端点>.

向根发出 get 会返回一个包含可用操作的目录。

问:register 的正确响应是什么，以告诉客户端下一步可以做什么(即登录)？

1. register 从技术上讲在服务器上创建了一个新资源，因此 201 CREATED 和 Location header 似乎是合适的。但是，login 引用并不是新创建资源的位置。

2. 我是否应该返回 201 Created，其中 Location 指向新创建的用户(例如 /myaccount 或 /users/{id} 然后在响应正文中包含登录链接？

    {
        _links: {
            self: { href: "what goes here?" },
            x:login: { href: "/login" }
        }
    }

我是否根本不告诉客户端，并要求他们在应用程序根目录上执行 get 操作，以获取可用端点的列表。无论如何，这应该包括登录。假设客户端必须首先执行此操作才能获取注册链接，它应该已经具有登录。

期望客户端已经拥有登录链接会让人感觉不舒服，因为它依赖于对客户端先前事件的假设。

要求客户端在注册后再次向根目录发出请求似乎很卑鄙、低效且不必要。如果客户端刚刚创建了一个资源，那么服务器应该响应下一步可以用它做什么似乎是公平的。

Answer 1

我希望我的 api 的行为与网页没有什么不同。如果您希望应用程序的用户体验是用户在注册后登录，则将其从成功注册的 302 到登录资源。成功登录后，将通过 302 将他们引导至适当的目的地(即，如果他们尝试访问没有 token 的内容，则带他们登录，并使用原始请求资源的目的地)。这是你的#3 的重要部分。具有导致登录的根链接，但您需要保护所有其他链接，以便它们指示(并链接到)访问资源需要登录。客户端应用程序应该期望随时获得此登录所需的响应，因为 token 可能(并且确实)随时过期。

接下来，将 JWT 作为 cookie 而不是授权 header 可能是有意义的，这会让客户端更容易一些(他们只需要设置一个 cookie jar)..如果客户端是指维护单个连接设置的 native 移动应用程序。如果是服务器到服务器，那么 auth header 就有意义。我会尽力支持两者以涵盖这两种情况。

继续将 api 视为网站的想法。为什么要让他们在注册后登录？为什么不让帐户注册以发送登录 token 结束呢？他们只是设置了用户/密码，为什么要让他们再次输入呢？我意识到在一些更奇特的架构中，注册服务无法执行登录操作(也许它没有私钥来签署 token )，但如果可能的话我会考虑它。

如果您确实想坚持使用 201 header (这很好，只需确保您的注册关系文档表明这一点)，那么我认为选项 2 是最接近的。刚刚创建的帐户 URL 的位置 header (201)对于创建用户来说是相当标准的。但是，我不会返回你在那里假设的东西。您正在返回一个帐户创建的资源(带有登录链接的东西)，但您真的需要这个自定义资源吗？如果您想在该资源中向客户端返回一些消息(例如“帐户已创建”)，那么绝对可以，但您也可以将根资源返回给他们。

tl；博士；决定您想要的 UX，然后让您的 API 实现您的 UX。