我正在尝试开发一个简单的REST API。我仍然试图理解它的基本架构范例。我需要以下方面的帮助：
“资源”应该是名词，对吧？所以，我应该有“用户”，而不是“getUser”，对吗？
我在某些API中看到了这种方法：www.domain.com/users/（返回列表），www.domain.com / users / user（针对用户执行某些操作）。这种方法好吗？
在我看过的大多数例子中，输入和输出值通常只是名称/值对（例如color ='red'）。如果我想发送或返回比这更复杂的内容怎么办？我是否只被迫处理XML？
假设PUT为/ user /方法将新用户添加到系统中。什么是输入参数的良好格式（假设所需的唯一字段是'用户名'和'密码'）？如果用户成功，会有什么好的回应？如果用户失败了（我想返回描述性错误消息）该怎么办？
什么是好的＆amp;简单的身份验证方法授权？我想将大多数方法限制为已成功“登录”的用户。每次通话都会传递用户名/密码吗？传递一个被认为更安全的令牌（如果是，如何在到期方面实施等）？
答案 0 :(得分：9)
对于第1点，是的。名词是预期的。
对于第2点，我希望/users能够给我一个用户列表。我希望/users/123能够给我一个特定的用户。
对于第3点，您可以返回任何内容。您的客户可以指定它想要的内容。例如text/xml，application/json等使用HTTP请求标头，您应该尽可能多地遵守该请求（尽管您可能只处理text/xml - 这将是在很多情况下是合理的。）
对于第4点，我希望POST 创建新用户。 PUT将更新现有对象。要报告成功或错误，您应该使用现有的HTTP成功/错误代码。例如200 OK。有关详细信息，请参阅this SO answer。
答案 1 :(得分：6)
REST最重要的约束是超媒体约束（“超文本作为应用程序状态的引擎”）。将您的Web应用程序看作是一个状态机，客户端可以请求每个状态（例如GET /user/1）。一旦客户端有一个这样的状态（想想：用户正在查看网页），它会看到一堆它可以遵循的链接转到应用程序中的下一个状态。例如，可能存在客户端可以遵循的“用户状态”链接以转到详细信息状态。
这样，服务器在运行时一次向客户端呈现应用程序的状态机一个状态。聪明之处：由于状态机一次是在运行时发现的，因此服务器可以在运行时动态更改状态机。
说完了......
on 1.资源基本上代表您要呈现给客户端的应用程序状态。通常会与域对象（例如用户）紧密匹配，但请确保您了解为您提供的表示不仅仅是序列化的域对象，而是Web应用程序的状态。
根据GET / users / 123思考是好的。不要在URI中放置任何操作。虽然没有害处（它只是一个不透明的字符串）但至少可以说是令人困惑的。
on 2.正如Brian所说。您可能需要查看Atom发布协议RFC（5023），因为它很好地解释了创建/读取/更新周期。
on 3.专注于面向文档的消息。媒体类型是REST的重要组成部分，因为它们（完全）提供应用程序语义。 不使用泛型类型，例如application / xml或application / json，因为您将围绕通常隐式的架构耦合客户端和服务器。如果没有什么能满足您的需求，只需自己填写。
也许您对我使用UBL进行黑客攻击的示例感兴趣：http://www.nordsc.com/blog/?cat=13
on 4.通常，使用POST / users /进行创建。看看RFC 5023 - 这将澄清这一点。这是一个易于理解的规范。
on 5.由于您无法使用会话（有状态服务器）并且是RESTful，因此您必须在每个请求中发送凭据。各种HTTP身份验证方案已经处理好了。它对缓存也很重要，因为HTTP Authorization标头对缓存有特殊的指定语义（没有公共缓存）。如果你把你的凭证塞进一个cookie中，你就会失去那个重要的部分。
所有HTTP状态代码都具有某种应用程序语义。使用它们，不要通过HTTP隧道传输自己的错误语义。
您可以访问#rest IRC或加入休息讨论雅虎进行详细讨论。
Jan