这是 REST 的正确实现吗？

Question

我正在稳步构建我的 API 的资源，但是在对构建 RESTful API 的正确方法进行了大量研究之后，我一直无法找到应该如何接收“复杂”请求的示例。

例如，作为登录过程的一部分（只不过是身份验证密钥更新），客户端会分派以下 URI：

/api/auth/login

URI 上没有值，资源是/auth/，被触发的命令是/login/。实际登录详细信息发送到服务器授权标头。

现在，促使我提出这个问题的原因是，当我正在编写一个命令以允许客户端获得密钥有效期的提醒时，我立即被 getkeyexpiration 或类似命令的东西所吸引名字。

突然觉得这听起来不像我在 6 个约束中读到的，这感觉更像是操作调用。

那么，基于上面的例子，这仍然是一个 RESTful API 吗？我很担心，因为我想不出一种方法来通过简单地使用 URI 资源名称和附加值来执行此操作。

谢谢

编辑：

阅读本文：http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http

我开始明白，通过用名词词命名资源和仅资源，服务器将如何运行的上下文变得更加清晰。

关于我上面的例子：

/api/auth/login

我使用 auth 作为登录的前缀，因为那是资源的上下文。我正在将我的系统设计为可扩展的，并且需要一种在 URI 级别对资源进行分类的方法。有这样做的标准方法吗？

Answer 1

你的 RESTful 资源应该是名词，因为 HTTP 提供了动词。

我会建议这样的东西：

/api/key

然后您可以 POST （包括 HTTP 授权标头）创建一个新密钥，返回如下内容：

/api/key/1234ABCDBLAHBLAH

这是一个特定于您的会话的密钥，然后您可以 GET 以检索有关它的详细信息，例如到期时间等。当然，您必须在每个后续请求中传递该密钥。

如果在 RESTful API 的上下文中讨论关键内容时听起来很笨拙，那是因为它通常是。会话是人类/浏览器的概念，但 RESTful API 是应用程序/集成的概念。

由于服务器不会“登录”到其他服务器，这就引出了一个问题：如果您已经同意要求调用者将 Auth 标头传递给您的登录 API，为什么不只要求将其传递给 每个 API 调用，完全忘记键的概念？