restful重定向和HttpStatus.docVIP

在项目中用到了rest重定向，他共有三种转态： //302????? @SuppressWarnings(rawtypes)?? ????@POST?? ????@Produces(MediaType.APPLICATION_JSON)?? ????@Path(/callbackRetUrl)?? ????public?javax.ws.rs.core.Response?callbackRetUrlRoute(@Context?HttpServletRequest?request)?throws?UnsupportedEncodingException,?URISyntaxException{?? ????????logger.debug(callbackRoute?callbackRoute?begin);?? ????????return?javax.ws.rs.core.Response.status(Status.FOUND).location(new?URI(http://localhost/#/account)).build();?? ????}?? ? ? Java代码?? //307?? javax.ws.rs.core.Response.temporaryRedirect(new?URI(http://localhost/#/account)).build();?? ? Java代码?? //303?? return?javax.ws.rs.core.Response.seeOther(new?URI(http://localhost/#/account)).build();? 《HTTP权威指南》第3章在讲解30X状态码时，完全没有讲清楚为什么要有302、303、307，以及他们的关系，一句“问题出在HTTP/1/1”让我一头雾水???莫名其妙；而第五章在讲重定向响应时，没有说到现在很常见的302，反而是说我从没遇到过的303和307。很是迷惑，对于这3个状态码，WiKi和RFC文档都有详解，下面我以我的思维添油加醋的描述一遍。 一、状态码——302 ? ? RFC1945( HYPERLINK /html/rfc1945 \l 34 /html/rfc1945#34)，也就是HTTP1.0在介绍302时说，如果客户端发出POST请求后，收到服务端的302状态码，那么不能自动的向新的URI发送重复请求，必须跟用户确认是否该重发，因为第二次POST时，环境可能已经发生变化（嗯，POST方法不是幂等的），POST操作会不符合用户预期。但是，很多浏览器（user agent我描述为浏览器以方便介绍）在这种情况下都会把POST请求变为GET请求。 ? ? RFC2616( HYPERLINK /html/rfc2616 \l section-10.3.3 /html/rfc2616#section-10.3.3)，也就是HTTP1.1在介绍302时说，如果客户端发出非GET、HEAD请求后，收到服务端的302状态码，那么就不能自动的向新URI发送重复请求，除非得到用户的确认。（又是-,-）但是，很多浏览器都把302当作303处理了（注意，303是HTTP1.1才加进来的，其实从HTTP1.0进化到HTTP1.1，浏览器什么都没动），它们获取到HTTP响应报文头部的Location字段信息，并发起一个GET请求。 二、状态码——303和307 ? ? 从上面的介绍可以知道，HTTP1.1和HTTP1.0的302状态码意义是一样的，浏览器对它的处理也是一样的。POST方法的重定向在未询问用户的情况下就变成GET，这种不符合文档规范的问题依然存在。实践在前而文档在后，HTTP1.1把这种POST变GET的行为纳入了RFC文档：HTTP1.1新加入303和307状态码。 ? ? 文档中规定303状态码的响应，也就是上边提到的现在浏览器对302状态码的处理：POST重定向为GET。 ? ? 307状态码则相当于HTTP1.0中302状态码，当客户端的POST请求收到服务端307的状态码的响应时，需要跟用户询问是否应该在新URI上发起POST方法，也就是说，307是不会把POST转为GET的。 ? ? 从网络上搜索到这个说法“303：对于POST请求，它表示请求已经被处理，客户端可以接着使用GET方法去请求Location里的URI。 307：对于POST请求，表示请求还没有被处理，客户端应该向Location里的URI重新发起POST请求。”，从上面的介绍可以明白，这个说法是臆想而已，文档并没有这么说，而业界是否统一如此处理，还不好说，我没有抓到过307和303的包。 ? ? 文档也说到，为兼容很多HTTP1.