细说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.总结

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