我正在稳步构建我的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级别上对资源进行分类的方法。有没有一种标准的方法呢？
答案 0 :(得分：1)
您的RESTful资源应该是名词，因为HTTP提供动词。
我会建议这样的事情：
/api/key
然后您可以POST（包含HTTP授权标头）创建一个新密钥，返回如下内容：
/api/key/1234ABCDBLAHBLAH
这是一个特定于您的会话的密钥，然后您可以通过GET来检索有关它的详细信息，例如到期时间等。当然，您必须在每个后续请求中传递该密钥。
如果在RESTful API的上下文中讨论关键内容听起来很笨，那是因为它通常是。会话是人/浏览器概念，但RESTful API是应用程序/集成概念。
由于服务器没有“登录”到其他服务器，这就引出了一个问题：如果您已经确定要求调用者将Auth标头传递给您的登录API，那么为什么不要求将其传递给< strong>每次 API调用，完全忘记密钥的概念？