基于身份验证的单一资源的RESTful方式

Question

我有一个API，它根据提供的身份验证（登录）提供帐户资源。由于用户只能拥有一个帐户，并且只能看到自己的帐户而不能看到其他帐户，因此在所有情况下，此API基本上都是一个资源API。

为了简单起见，我将此资源放在网址accounts/下，当您访问accounts/?username=dude&password=veryhard时，您将获得您的帐户数据（如果您没有提供身份验证，则会获得403）。

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

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

Answer 1

1. 是帐户/？username = dude＆amp; password = veryhard是一个正确的REST URL。
2. 如果用于更新资源，则PUT与id一起使用，如果使用它来创建，则必须提供ID。否则你使用post来创建一个没有id的资源

Answer 2

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

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

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