细说Redirect重定向请求（情节分享）

前些日子在开发公司项目接口的时候，由于需要与第三方平台对接，由于接口之前的层层封装，不断的需要转发，把人差点搞糊涂了。本来以为之前对Redirect的认识足够清楚，可是到实际开发之前我还是没有把这个问题想清楚，从而造成了需要花费更多的时间解决问题。总结下，并分享。

1.请求转发（forward）:

当客户端（浏览器）向远程服务器发送一个URL(http://www.cnblogs.com/zivxiaowei/)GET请求后，服务器接收到请求后，会在服务器内部直接通过另外的一个URL获取资源，并将此资源再响应给浏览器，也就是说请求转发整个过程是一次性的。列如：

->在浏览器中看到这URL（http://www.cnblogs.com/zivxiaowei/），

->通过页面上的点击操作后，

->服务器响应了其他页面内容到浏览器，但是浏览器的URL地址仍然是原来的URL.

2.重定向（Redirect）:

当客户端（浏览器）向服务器发送一个URL请求后，但是资源并不在当前请求的服务器上，此时服务器会告诉浏览器，资源在另外一个URL地址上，此时浏览器会重新发送请求到新的资源地址。例如：

->在浏览器中看到这URL（http://www.cnblogs.com/zivxiaowei/），

->服务器A响应浏览器重定向

->浏览器重新定位新的URL地址到服务器B

->服务器B响应内容到浏览器，此时浏览器上面的URL已经换位了新的资源请求地址

3.场景：

现在又服务器：A,B,C,D, ABC都是本公司服务器，A服务器为Web服务器，而D为合作伙伴提供的接口服务器。

公司Web项目A需要调用服务器D的远程鉴权接口，而我司又通过B,C两个服务器对D服务器的鉴权接口进行了封装，

然后web服务器A会通过调用服务器B，B调用服务器C，C调用D的方式调用鉴权接口（有点烦人，但是他们要求这么做）。

服务器D本来可以直接通过响应JSON/XML数据来提供接口的，但是他们做了业务逻辑封装，

1. 当发现请求鉴权不通过的时候，D服务器会重定向到他们的Web页面，当用户在界面上操作完成后，D服务器会发送重定向请求到调用者制定的接口，然后调用者通过解析重定向请求的数据完成接下来的操作。
2. 当调用者发送的请求通过了服务器D鉴权的时候，服务器D会直接重定向响应到调用者制定的接口，然后调用者通过解析重定向请求的数据完成接下来的操作。

　　简而言之，对接服务器D,需要其他服务端不断的发送重定向请求。愚蠢的是，由于当时没想明白整个重定向流程，对接的时候，我把服务器D重定向的结果地址写在了服务器B上接收，然后把数据封装成了JSON。最后造成的结果就是，当用户在浏览器上访问服务器A时，服务器响应的都是数据，Web服务器A根本就没有进行过业务逻辑处理。最后又不得重新修订了下接口，重定向结果请求还是得放在Web端。

4.总结

接口的制定是一深度技术活，设计不好就是个大坑。了解清楚重定向，以后碰到了少走点弯路，少入点坑。（描述的肯能不是很清楚，见谅）

作者：Ziv小威
出处：http://www.cnblogs.com/zivxiaowei/
关于作者：专注于Java技术的程序员一枚，此外对JS开发保持着较高的兴趣。爱好音乐，阅读，FM等等。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接。
如有问题，可以邮件：[e-mail]
微博：Ziv小威