我有两个资源：客户和用户
每个客户可以有多个用户。用户仅存在于客户中。
我在前端有一个页面，该页面可同时从客户和用户收集数据，以创建客户及其第一个用户。
示例：客户名称，用户密码，用户电子邮件
我想在Rest API上创建该客户和该用户。我应该如何处理？
我的第一个念头是：
POST /customer
body: {name: foo}
return {customer resource}
然后：
POST /customer/{id}/user
{email: [email protected], password: secret}
return {user resource}
但是，如果用户创建失败，则必须删除该客户。但是，当创建用户的请求正在进行时，最终用户可能会关闭浏览器，如果没有用户，我会丢失一个客户。
我的第二个想法是创建和帐户终结点，他不是数据库中的资源，并且：
POST /account
{customer_name: foo, user_email: [email protected], user_password: secret}
return {user resource}
有任何道理吗？其他想法？
我想在Rest API上创建该客户和该用户。我应该如何处理？
考虑如何在网络上进行。
您可能会有某种注册页面，该资源包括表单的表示形式。表单的输入控件将向访问者描述所需的信息。当访问者单击“提交”按钮时，浏览器将产生一个与HTML的表单处理服务器一致的HTTP请求，并将该请求分派回服务器。服务器从消息有效负载中读取信息，完成工作，然后将状态，附加信息，指向其他有趣资源的链接等其他网页发送回客户端。
对于交互协议的一部分，它是不安全（意味着，请求的语义并非有效地只读），因为可能是“注册”，因此该表单将指定使用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">