配置文件/帐户 REST API 命名约定答案

【问题标题】：Profile/account REST API naming convention配置文件/帐户 REST API 命名约定
【发布时间】：2015-08-26 01:59:37
【问题描述】：

我尝试在网上搜索，但没有找到以下请求的最佳实践 URL 命名约定示例。
我的 API 允许用户登录系统，检索可用于通过 HTTPS 访问私人数据的安全令牌。

因此 API 将支持以下功能：

授权。简单的认证。 /api/auth 将用于首次登录系统并获取令牌作为响应或在需要时刷新过期令牌。
查看个人资料数据（名字、姓氏、电话号码......）。为该资源形成 url 的最佳方法是什么。我有几个想法：/api/users/me/profile OR /api/users/{id}/profile。在第一种情况下，我们的客户端（REST API 使用者）不需要知道用户的确切 ID，当用户尝试访问此资源时，它会检查令牌是否有效，传递的用户名是否存在并绑定到令牌，而不仅仅是根据此信息返回数据。在第二种情况下，我们必须知道用户的确切 ID，当然这个 ID 可以返回以响应身份验证。
还有其他方法，例如/api/user/me/orderlist, /api/user/me/someuserspecificinfo。
如何下订单。我已阅读如果您需要创建新资源，则必须使用 POST，如果更新 - PUT。我的网址应该是什么样子？

/api/neworder (parameters in post body), /api/user/neworder , /api/orders (just with post method)

.......

请建议此类资源的常用命名约定是什么

【问题讨论】：

【解决方案1】：

您的资源 URI 应该或多或少是恒定的，并且 HTTP 动词决定执行什么操作，例如：

/api/orders:

/api/orders/{order-id};

在您的 REST API 中加入类似函数的名称，例如 /api/user/neworder，是吸引 REST 原教旨主义者愤怒的好方法。

【讨论】：

非常感谢您的解释，请建议如何处理第二个问题？如何为用户配置文件形成 URI？
@CRASP 看起来不错？我使用过的大多数 API 都使用“厨房水槽”方法，并且只提供 /api/resource/{id} 端点中的每一块数据，因为许多人似乎认为发出多个 HTTP 请求是“浪费的”，但除此之外还有没有理由你不能像这样将用户信息分成更小的块。
是的，你的方法很棒，我想知道如何获取当前用户或者它是多余的，只使用 /users/profile 或 /users/{id}/profile 或 /users/me/profile。我唯一担心的一件事是我必须知道确切的用户 ID 还是没问题？如果我尝试访问其他用户信息，令牌检查将失败
@CROSP REST 不是一个严格的标准，它更像是一种风格。您当然可以实现/users/me 资源，但 REST 纯粹主义者希望端点是无状态的 [认为“没有 cookie，没有会话”] 所以除非您在请求标头中包含一些其他信息来表示您可能强加的身份端点上的状态fulness。如果是我，我会简单地将 $me = '{user-id}'; 存储在客户端中。