REST API 设计：依赖资源

Question

我有两个资源：客户和用户

每个客户可以有多个用户。 用户只存在于客户中。

我在前端有一个页面，它同时从客户和用户那里收集数据，以创建客户及其第一个用户。

示例：客户名称、用户密码、用户 email

我想在 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}

有任何意义吗？ 其他想法？

Answer 1

我想在 Rest API 创建那个客户和那个用户。 我应该如何处理？

想想你将如何在 web 上做到这一点。

您可能会有某种注册页面，一种包含表单表示的资源。 表单的输入控件将向访问者描述所需的信息。 当访问者点击提交按钮时，浏览器产生一个与 HTML 表单处理服务器一致的 HTTP 请求，并将该请求分派回服务器。 服务器从消息负载中读取信息，它是否正常工作，然后将另一个 web 页面发送回客户端，其中包含状态、附加信息、指向其他有趣资源的链接等。

对于不安全的交互协议的一部分（意味着，请求的语义不是有效的只读），因为“注册”可能是，表单将指定在请求行中使用 POST 方法令牌HTTP 请求。

该目标 URI 可以是任何东西 - 浏览器将复制服务器指定的任何 form.action。

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

将是一个非常好的选择（尽管它可能会让那些试图通过查看 HTTP 日志来弄清楚发生了什么事情的操作员感到失望）。

通常，对于开始有趣过程（如初始注册）的消息，使用具有集合语义的资源标识符。 所以这可能更熟悉

POST /signups

您可以在处理 POST 请求时创建额外的资源（是的，不止一个）； 因此您的注册 POST 处理程序可以为客户和用户创建资源。

这些资源中的每一个都有自己的 URI。

/companies/1
/users/3

那会很好。 从机械上讲，对两者使用共同的阀杆可能会有优势。 同样，日志中的语义提示可以帮助操作员进行调查。 此外，如果两个 URI 具有相同的根，您可以使用点段，以更通用的方式从另一个资源引用一个资源

<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">