0

我正在稳步构建我的 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 级别对资源进行分类的方法。有这样做的标准方法吗？

4

1 回答 1

1

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

我会建议这样的事情：

/api/key

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

/api/key/1234ABCDBLAHBLAH

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

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

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

于 2012-10-31T19:32:00.253 回答