Tag: rest

REST中的OAuth令牌和会话: 另一分钟我读了一篇关于OAuth的文章。它特别描述了一系列请求期间客户端和服务提供者之间交换的令牌。文章还提到OAuth作为授权层在RESTful API中获得了显着的普及。据我了解，REST应该保持完全无状态。问题：这个重复的令牌不会交换鱼雷REST的“无状态”原理吗？恕我直言，令牌可以被看作是一种会话ID，不是吗？

Spring Security – 基于令牌的APIauthentication和用户/密码authentication: 我正在尝试创build一个Web应用程序，主要是使用Spring提供一个REST API，并试图configuration安全方面。我试图实现这种模式： https ： //developers.google.com/accounts/docs/MobileApps （谷歌已经完全改变了这个页面，所以不再有意义 – 请参阅我在这里指的页面： http： //web.archive.org/web/20130822184827/https://developers.google.com/accounts/docs/MobileApps ）这是我需要实现的： Web应用程序具有简单的login/registry单，可以和普通的spring用户/密码authentication一起工作（之前用dao / authenticationmanager / userdetailsservice等做过这种types的事情） REST API端点是无状态会话，并且每个请求都是基于随请求提供的令牌进行身份validation的（例如，用户使用常规表单login/注册，webapp提供安全的cookie和令牌，然后可以在以下API请求中使用）我有一个正常的身份validation设置如下： @Override protected void configure(HttpSecurity http) throws Exception { http .csrf() .disable() .authorizeRequests() .antMatchers("/resources/**").permitAll() .antMatchers("/mobile/app/sign-up").permitAll() .antMatchers("/v1/**").permitAll() .anyRequest().authenticated() .and() .formLogin() .loginPage("/") .loginProcessingUrl("/loginprocess") .failureUrl("/?loginFailure=true") .permitAll(); } 我正在考虑添加一个pre-authfilter，检查请求中的令牌，然后设置安全上下文（这意味着正常的后续authentication将被跳过？），但是，超出正常的用户/密码我有基于令牌的安全性并没有做太多的事情，但是基于其他一些例子，我提出了以下内容：安全configuration： @Override protected void configure(HttpSecurity http) throws Exception { […]

对于需要SSL / TLS的请求发送适当的HTTP响应是什么？: 我正在devise一个RESTful API，其中一些调用是通过HTTP公开的，有些需要API密钥并通过HTTPSencryption。我正在考虑如果HTTP请求发送到其中一个私有资源应该发送什么响应代码。到目前为止唯一跳出来的是412 –先决条件失败，但是标准表明，先决条件是由请求者而不是服务器强加的。对于这种情况，有没有适当的回答代码，或者我只需要放弃和做400 ？

正确的REST格式的URL与date范围: 我有一个REST URL来获取所有格式化的用户： http : //example.com/users 要通过id获取个人用户： http ： //example.com/users/12345 要获取所有用户的出价： http ： //example.com/users/12345/bids 要在两个date之间获得所有用户的出价，请执行以下操作： http : //example.com/users/12345/bids/?start=01/01/2012&end=01/31/2012 或者应该是这样的： http : //example.com/users/12345/bids/start/01012012/end/01312012 我倾向于第一个date范围url，因为开始和结束不是域中的实体。使用date范围格式化RESTurl的正确方法是什么？谢谢，汤姆

REST：HTTP头或请求参数: 我一直在围绕REST进行一些研究。我注意到， Amazon S3 API主要为其REST接口使用http标头。这对我来说是一个惊喜，因为我认为这个接口主要用于请求参数。我的问题是这样的：我应该主要使用HTTP头来开发我的REST接口，还是应该使用请求参数？

如何在JAX-RS中设置响应头，以便用户看到Excel的下载popup窗口？: 我编写了使用REST JAX-RS生成Excel文件的代码，并确认生成的Excel文件位于GlassFish服务器目录中。但是我的目标是当用户点击button（生成Excel .xls）时，我想下载popup窗口，显示询问用户是否要保存或打开.xls文件，就像其他Web服务一样，下载任何types的文件。根据我的search，步骤是：生成Excel .xls（DONE）写excelstream 在JAX-RS文件中，将响应头设置为类似的东西， String fileName =“Blah_Report.xls”; response.setHeader（“Content-Disposition”，“attachment; filename =”+ fileName）; 我的问题是我在JAX-RS文件中做了所有这一切，我没有可用的HttpServletResponse对象。根据添加响应头到JAX-RS Webservice的答案他说：你可以在你的webservice中通过@Context注释来注入对实际HttpServletResponse的引用，并使用addHeader（）等来添加你的头文件。没有示例代码，我无法确切地说明究竟是什么意思。

使用android-async-http（loopj）发布JSON / XML: 我使用的是android-async-http ，真的很喜欢它。我遇到POST数据的问题。我必须以以下格式将数据发布到API： – <request> <notes>Test api support</notes> <hours>3</hours> <project_id type="integer">3</project_id> <task_id type="integer">14</task_id> <spent_at type="date">Tue, 17 Oct 2006</spent_at> </request> 根据文档，我尝试使用RequestParams ，但它是失败的。这是否有其他的方式来做到这一点？我也可以发布相当于JSON。有任何想法吗？

把详细的REST错误消息放在HTTP警告头，好/坏主意？: 如果出现问题，我们正在开发一个使用HTTP状态代码作为响应代码的标准REST服务。（例如，无效的用户input将向客户端返回“400错误请求”）但是，我们觉得更详细的错误信息对于客户是有用的。（例如，无效input错误是由于X是无法识别的参数名称）我们希望尽可能忠实于HTTP规范，所以在研究了RFC2616中的规范后，我们正在考虑将详细的错误消息放在HTTP头中，特别是在HTTP头警告字段中。它在RFC上说：警告通用标题字段用于携带有关消息的状态或转换的附加信息，这些消息可能不会反映在消息中。这些信息通常用于警告caching操作或应用于消息的实体主体的转换可能缺乏语义透明度。对于其他警告（比如REST错误消息），使用这个头文件似乎没有任何限制，甚至那些与这个头文件的初始意图无关的caching警告也是如此。我们喜欢语义，我们计划使用299警告代码，这似乎很适合这个法案：其他持续性警告警告性文本可能包含任何要呈现给用户的信息或logging 。接收到此警告的系统不得采取任何自动操作。所以，考虑到在这个问题的顶部提出了无效的input错误的情况下，我们正在考虑把我们的REST错误消息，如下面的例子： HTTP/1.1 400 Bad Request Warning: 299 ServiceName "Invalid input error: X is unrecognized parameter name." 这是一个好主意/练习吗？我们还发现一些服务在X-Warning标题中详细描述了这个消息，但是这似乎不是标准的。我们想知道，stackoverflow REST人群的蜂巢智慧会怎么想呢？在REST响应中是否还有更好的/标准化的实践来传递详细的错误消息？

RESTful和RESTless之间有什么不同？: 平静和不安的基本区别是什么，我一直在阅读一些文章，人们似乎交替使用它们。

使用http状态202进行asynchronous操作: 我正在编写一个REST API来接受用户提供的数据。我想保持所有操作完全asynchronous，这包括PUT，POST，DELETE甚至GET请求。我的想法是接收请求，处理它足以确保它是一个有效的请求，然后传递一个HTTP 202接受的响应连同数据将最终可用的URL和令牌，以便后续的请求可以匹配处理的数据。如果请求无效，那么我将发送一个HTTP 400。然后客户将负责检查我在将来某个时间提供给他们的url，并传递令牌。如果数据可用，则返回正常的200或201，但是如果我仍在处理请求，则会发送另一个202，指示处理尚未完成。如果处理数据出错，我会根据需要发送4xx或5xx状态。我想这样做的原因是我可以将所有有效的请求转储到请求池中，并让工作人员从队列中拉出来，并在请求可用时处理请求。由于我不知道游泳池的大小或可用的工作人员数量，我不能确定我是否可以快速获得足够的要求来满足Google App Engine的30秒限制。我的问题是：我是通过这种方式处理请求歪曲REST？例如，浏览器似乎需要立即回应请求。对于我的HTML页面，我计划用结构化页面进行响应，然后使用AJAX处理数据请求。我最感兴趣的是以这种方式使用REST处理数据的任何意见或经验。