场景
前端本地开发,接口代理,页面代理,文件代理
- 本地开发时可封装统一的
request
方法,针对接口请求统一加上/api
前缀。针对一些特定场景如APP内嵌H5项目,通过Bridge传入的参数,或者获取参数的方法,每次请求都需附带则可以通过拦截器
针对请求前的参数进行修改, 在此处也可针对特定地址的接口进行特定的调整。而返回值的错误处理,如非正常状态的HTTP Status
错误处理,可在response
中进行拦截,如会话失效返回的401
捕捉并进行重定向到登陆页面。 - 跨域有多种解决方案,但是代理是其中较为简单且解决比较完善的方案。
本地开发使用的各种前端脚手架,基本支持
Proxy
的配置,结合上文request
方法统一加上的/api
前缀,可在Proxy
中直接针对/api
路径进行代理配置,changeOrigin
并且target
到指定的后端接口url
。不同环境的baseUrl
也就无需配置。开发时不同环境的后端接口可能会出现不同,可通过CROSS ENV
注入环境变量,针对环境变量维护一份接口地址Map
,如:export const targetUrl = { dev: 'DEV_API_BASE_URL', test: 'TEST_API_BASE_URL', uat: 'UAT_API_BASE_URL', }
2.针对可能出现的iframe
嵌套进组件的需求,也可以单独部署到其他服务器,如专门的pdf预览用页面,iframe的跨域问题和pdf文件的跨域问题,都可以通过配置Proxy
来解决,如设置前缀/viewer
与/file
代理到对应的页面服务器与OSS文件服务器。
注意,目前涉及到的代理都是本地开发时候的脚手架提供的代理能力,部署后将失效,需要在服务端配置代理,一般使用
Nginx
的反向代理能力。
3.部署。部署涉及到的代理与本地的Proxy
基本一一对应,可参考如下Nginx
反向代理配置。
location ^~/api/ {
proxy_pass API_BASE_URL;
}
注意斜杠。实际上反向代理是屏蔽了服务端,拦截了前端项目的访问路径,通过本机Nginx代理到不同目标服务器,这一过程对客户端来说是无感知的。而正向代理则刚好相反,代理了客户端,服务端对不同客户端是无感知。