Questions tagged «rest»

REST(表示状态传输)是一种用于分布式超媒体系统(例如,万维网)的软件体系结构。相对于RPC体系结构(例如SOAP),由于客户端与服务器之间的固有解耦(由于异构系统之间具有统一的接口),它的流行度有所提高。

12
REST API错误返回良好做法[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 3年前关闭。 我正在寻找有关从REST API返回错误的良好实践指南。我正在开发一个新的API,所以我现在可以朝任何方向发展。目前,我的内容类型是XML,但我计划将来支持JSON。 我现在添加了一些错误情况,例如,某个客户端尝试添加新资源,但已超出其存储配额。我已经在使用HTTP状态代码处理某些错误情况(身份验证为401,身份验证为403,普通错误请求URI为404)。我查看了受祝福的HTTP错误代码,但400-417范围似乎都不适合报告应用程序特定的错误。因此,起初我很想以200 OK和特定的XML有效负载返回我的应用程序错误(即,向我们支付更多,您将获得所需的存储空间!),但我停下来考虑一下,而且似乎很肥皂水(/耸了耸肩)。除此之外,感觉像是将错误响应分为不同的情况,因为有些是http状态代码驱动的,而另一些则是内容驱动的。 那么行业的建议是什么?良好做法(请解释原因!),以及从客户端pov看,REST API中的哪种错误处理使客户端代码的工作变得更轻松?
622 web-services  http  rest 

10
了解REST:动词,错误代码和身份验证
我正在寻找一种在基于PHP的Web应用程序,数据库和CMS中将API围绕默认功能包装的方法。 我环顾四周,发现了几个“骨架”框架。除了我的问题的答案之外,还有Tonic,我喜欢它是REST框架,因为它非常轻巧。 我最喜欢REST的原因在于它的简单性,并希望基于它创建一个API架构。我正在努力了解基本原理,但尚未完全理解它。因此,有很多问题。 1.我理解正确吗? 说我有一个资源“用户”。我可以像这样设置许多URI: /api/users when called with GET, lists users /api/users when called with POST, creates user record /api/users/1 when called with GET, shows user record when called with PUT, updates user record when called with DELETE, deletes user record 到目前为止,这是RESTful架构的正确表示吗? 2.我需要更多动词 从理论上讲,创建,更新和删除可能就足够了,但实际上,我将需要更多的动词。我知道这些事情,可以嵌入到更新请求,但他们是可以有具体的返回代码的具体行动,我不希望他们全部扔进一个动作。 在用户示例中想到的一些是: activate_login deactivate_login change_password add_credit …
602 web-services  rest 

15
REST和RESTful有什么区别
REST系统和RESTful系统之间有什么区别? 从我读得最多的几件事中,所谓的REST服务实际上就是RESTful服务。那么两者之间有什么区别。
540 architecture  rest 

16
如果REST应用程序应该是无状态的,那么如何管理会话?
我需要一些澄清。我一直在阅读有关REST和构建RESTful应用程序的信息。根据维基百科,REST本身被定义为“ 代表性状态转移”。因此,我不理解每个人不断涌出的所有无状态gobbledeygook。 从维基百科: 在任何特定时间,客户端可以在应用程序状态之间转换,也可以“静止”。处于休息状态的客户端可以与其用户进行交互,但是不会造成负载,也不会消耗服务器集或网络上的每个客户端存储。 他们只是在说不使用会话/应用程序级别的数据存储吗??? 我知道REST的一个目标是使URI访问保持一致和可用,例如,而不是在帖子内部隐藏分页请求,而使请求的页码成为GET URI的一部分。我感觉合理。但是,似乎没有任何理由说每个客户端数据(会话数据)都不应存储在服务器端。 如果我有一条消息队列,并且我的用户想阅读消息,但是在阅读过程中,他想在会话期间阻止某些发件人消息通过,该怎么办?将其存储在服务器端的某个位置,让服务器仅发送未被用户阻止的消息(或消息ID),这是否有意义? 每次我请求新的消息列表时,是否真的必须发送整个消息发件人列表才能阻止?首先,与我相关的消息列表甚至不会/也不应该是公共可用的资源。 同样,只是试图理解这一点。请有人澄清。 更新: 我发现了一个堆栈溢出问题,该问题的答案并不能完全解决我的问题: 如何在REST 中管理状态,该状态表示重要的客户端状态应在每个请求上全部转移。 ..似乎有很多开销...是这样吗?

22
REST URI约定-创建资源时的单数或复数名称
我是REST的新手,我注意到在某些RESTful服务中,它们使用不同的资源URI进行更新/获取/删除和创建。如 创建-使用/资源用POST方法(注意复数),使用一些地方/资源(单数) 更新-使用/ resource / 123和PUT方法 获取-将/ resource / 123与GET方法一起使用 我对此URI命名约定有点困惑。我们应该使用复数还是单数来创建资源?决定的标准是什么?

4
用于Web服务响应的text / xml与application / xml之间有什么区别
这是更多的区别一般问题text/xml和application/xml。我是写Web服务的新手(REST-Jersey)。我一直在制作,application/xml因为它是我一直在学习的大多数教程/代码示例中所显示的内容,但是最近我发现了它,text/xml并想知道它有什么不同之处以及何时使用它application/xml?
494 xml  rest  jersey 

7
会话真的违反了R​​ESTfulness吗?
在RESTful API中使用会话是否真的违反了R​​ESTfulness?我已经看到许多意见朝着任何方向发展,但是我不相信会议是RESTless的。从我的观点: RESTfulness禁止身份验证(否则RESTful服务将很少使用) 通过在请求中发送身份验证令牌(通常是标头)来完成身份验证 该身份验证令牌需要以某种方式获得,并且可能会被吊销,在这种情况下,需要对其进行续订 身份验证令牌需要由服务器验证(否则将不是身份验证) 那么会话如何违反此规定? 客户端,使用cookie实现会话 Cookies只是一个额外的HTTP标头 可以随时获取并撤消会话Cookie 如果需要,会话cookie可以有无限的生存时间 会话ID(身份验证令牌)在服务器端经过验证 因此,对于客户端而言,会话cookie与任何其他基于HTTP标头的身份验证机制完全相同,只是它使用Cookie标头代替Authorization或其他专有标头。如果没有会话附加到Cookie值服务器端,那为什么会有所作为?只要服务器表现为 RESTful ,服务器端的实现就不必关心客户端。因此,Cookie本身不应使API 成为RESTless,而会话只是客户端的Cookie。 我的假设错了吗?是什么使会话cookie 无需REST?

22
设置HttpClient的授权标头
我有一个用于REST API的HttpClient。但是,我在设置Authorization标头时遇到了麻烦。我需要将标头设置为通过执行OAuth请求收到的令牌。我看到了.NET的一些代码,这些代码建议如下: httpClient.DefaultRequestHeaders.Authorization = new Credential(OAuth.token); 但是,WinRT中不存在Credential类。任何人有任何想法如何设置授权标头?

6
连字符,下划线或驼峰作为URI中的单词定界符?
我正在为Intranet应用程序设计基于HTTP的API。我意识到在宏伟的事物中这是一个很小的问题,但是:我应该使用连字符,下划线还是camelCase来分隔URI中的单词? 这是我最初的想法: 骆驼香烟盒 如果服务器不区分大小写,则可能出现问题 似乎在查询字符串键(相当广泛使用http://api.example.com?SEARCHQUERY = ...),而不是在其他URI部分 连字号 比其他替代品更美观 似乎在URI的路径部分中被广泛使用 在野外从未见过带连字符的查询字符串键 对于SEO 可能更好(这可能是神话) 下划线 编程语言可能更容易处理 几个流行的API(Facebook,Netflix,StackExchange等)在URI的所有部分都使用下划线。 对于所有内容,我都倾向于强调。大多数大型参与者都在使用它们,这一事实令人信服(请参阅https://stackoverflow.com/a/608458/360570)。
475 api  url  rest  uri  restful-url 

2
使用JAX-RS和Jersey进行基于REST令牌的身份验证的最佳实践
我正在寻找一种在Jersey中启用基于令牌的身份验证的方法。我正在尝试不使用任何特定的框架。那可能吗? 我的计划是:用户注册我的Web服务,我的Web服务生成令牌,并将其发送给客户端,客户端将保留它。然后,对于每个请求,客户端将发送令牌,而不是用户名和密码。 我正在考虑为每个请求使用自定义过滤器, @PreAuthorize("hasRole('ROLE')") 但是我只是认为这会导致对数据库的大量请求检查令牌是否有效。 还是不创建过滤器,并在每个请求中放置一个参数令牌?这样每个API都会先检查令牌,然后再执行一些操作来检索资源。

11
捕获request.GET中的url参数
如教程中所述,我目前正在定义正则表达式以捕获url中的参数。我如何从url作为HttpRequest对象的一部分访问参数?我HttpRequest.GET当前返回一个空QueryDict对象。 我想学习如何在没有库的情况下执行此操作,以便更好地了解Django。
457 django  url  rest 

7
如何设计RESTful搜索/过滤?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 2年前关闭。 我目前正在用PHP设计和实现RESTful API。但是,我一直无法实现我的初始设计。 GET /users # list of users GET /user/1 # get user with id 1 POST /user # create new user PUT /user/1 # modify user with id 1 DELETE /user/1 # delete user with id 1 到目前为止,还算标准,对吗? 我的问题是第一个GET /users。我正在考虑在请求正文中发送参数以过滤列表。这是因为我希望能够指定复杂的过滤器而无需获取超长网址,例如: GET /users?parameter1=value1&parameter2=value2&parameter3=value3&parameter4=value4 相反,我想拥有类似的东西: GET /users # …
456 api  search  rest  filter 

7
带有URL查询参数的HTTP POST-好主意吗?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 2年前关闭。 我正在设计一个通过HTTP的API,我想知道是否使用HTTP POST命令,但仅使用URL查询参数,而没有请求主体,是一种不错的方法。 注意事项: “良好的Web设计”要求通过POST发送非幂等动作。这是非幂等的动作。 当请求参数出现在URL中时,开发和调试该应用程序会更加容易。 该API并非旨在广泛使用。 似乎没有主体地发出POST请求将花费更多的工作,例如Content-Length: 0必须显式添加标头。 在我看来,没有主体的POST有点违反大多数开发人员和HTTP框架的期望。 通过URL查询而不是请求正文在POST请求上发送参数是否还有其他陷阱或优势? 编辑:正在考虑的原因是该操作不是幂等的,并且具有除检索之外的副作用。参见HTTP规范: 特别是,已经建立了约定,即GET和HEAD方法不应具有除检索之外的其他任何操作。这些方法应该被认为是“安全的”。这允许用户代理以特殊方式表示其他方法,例如POST,PUT和DELETE,以便使用户知道请求了可能不安全的操作这一事实。 ... 方法还可以具有“幂等”的特性,因为(错误或过期问题除外)N> 0个相同请求的副作用与单个请求的副作用相同。GET,HEAD,PUT和DELETE方法共享此属性。同样,方法OPTIONS和TRACE不应有副作用,因此本质上是幂等的。
451 rest  http 


10
注销:GET还是POST?
这个问题与一般何时使用GET或POST无关。推荐使用哪种方法来处理从Web应用程序注销。在一般意义上,我已经找到了很多有关GET和POST之间差异的信息,但是对于这种特殊情况,我没有找到确切的答案。 作为实用主义者,我倾向于使用GET,因为实现它比POST更简单。只需删除一个简单的链接就可以了。我可以想到的绝大多数网站都是这种情况,至少从我的脑海中可见。甚至Stack Overflow也可以使用GET进行注销。 让我犹豫的是(尽管是旧的)论点,即某些Web加速器/代理通过转到并检索他们在页面中找到的每个链接来预缓存页面,因此用户单击它们时可获得更快的响应。我不确定是否仍然适用,但是如果是这种情况,那么理论上具有这些加速器之一的用户将在登录后立即被踢出应用程序,因为她的加速器将查找并检索注销链接,即使她从未点击过它。 到目前为止,我所读的所有内容都建议将POST用于“破坏性操作”,而不会改变应用程序内部状态的操作(如查询等)应使用GET处理。基于此,这里的真正问题是: 从应用程序注销是否被认为具有破坏性,是否会改变应用程序的内部状态?
434 architecture  rest  post  get 

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.