0

我有一个 API，它根据提供的身份验证（登录）提供帐户资源。由于一个用户只能有一个账号，而且只能看到自己的账号，看不到别人的账号，所以这个API在所有情况下基本上都是一个单一的资源API。

所以为了简单起见，我在 url 下有这个资源accounts/，当你访问时，accounts/?username=dude&password=veryhard你会得到你的帐户数据（如果你不提供身份验证，你会得到 403）。

现在我想知道这是否是 RESTful 的。此外，您应该能够更新您的帐户信息，我想知道 PUT 是否合适。据我所知，PUT 应该在资源的唯一 URI 上完成。那么，这是资源的唯一 URI 吗？通常，帐户的 URI 看起来像帐户 IDaccounts/3515/在哪里。3515但是，用户不知道他们的帐户 ID。此外，应该有更多的登录方式，而不是用户名 + 密码，您还应该能够使用令牌（如accounts/?token=d3r90jfhda139hg）。那么我们得到了 2 个指向同一个资源的 URL，这对于 RESTful URI 来说也不是很漂亮，是吗？

那么，什么是最 RESTful 的解决方案？还是我不应该这样做 RESTful？

4

2 回答 2

2

REST 纯粹主义者会认为使用/accounts/来获取单个帐户是不好的做法，因为它应该指定一个集合。相反，请考虑一个不会被误认为是 ID 的密钥，例如，如果您的 ID 是 UUID，则使用诸如“我”之类的令牌，因此您的 URL 是/accounts/me. 这样做的好处是，如果以后您希望获得不同的帐户信息，例如您需要列出用户或者您有一个使用相同 API 的管理系统，那么您可以轻松扩展它。

将用户名和密码放在 URL 中也不是纯 REST。查询参数应与您获取的资源直接相关；通常过滤和限制返回的资源。相反，您应该认真考虑通过加密 (HTTPS) 连接使用 HTTP Basic 身份验证，以便将身份验证/授权和资源系统分开。如果您更喜欢使用令牌系统，请查看 oauth 或 hawk。

最后，是的，如果您使用 PUT，您应该提供完整的资源标识符。鉴于系统在更新数据之前读取数据是很常见的，因此缺少 ID 不会成为问题，因为它将作为先前 GET 的一部分返回。

于 2013-09-24T16:29:53.730 回答
1
  1. 是的 accounts/?username=dude&password=veryhard 是正确的 REST URL。
  2. 如果 PUT 用于更新资源，则 PUT 与 id 一起使用，如果您使用它来创建，则必须提供 ID。否则你使用 post 创建一个没有 id 的资源
于 2013-09-24T15:31:44.013 回答