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