之前寫的這個系列的時候,是看了一些資料以後經過實操,從一個前端初學者的角度記錄驗證過程。php
可是,在近年來的工做中發現用到的場景並很少,實際工做中大部分遇到的跨域問題仍是在調用接口時。前端
雖然有了CORS方案,可是對我來講,CORS實際開發中並不友好。首先它不支持低版本瀏覽器,固然如今前端開發基本能夠忽略這個問題了,更主要的是CORS是須要服務器配置的,而這個通常是後臺同事負責。第一次接口請求報錯了,提醒他們要加上容許請求的域,後來接口新增了新的請求方法或請求頭字段,又要提醒他們,遇到有經驗又有耐心的後臺開發小哥哥還好,否則就等着吧。webpack
咱們回到本質,爲何會有跨域問題,緣由是瀏覽器的同源策略。因此若是調用的接口與頁面同域或調用接口的不是瀏覽器就沒有跨域問題了。如今把二者結合起來就能夠實現跨域請求,即前端把請求發送給頁面服務器,頁面服務器請求接口服務器,拿到數據後再返回給前端,這裏頁面靜態服務器充當了代理/轉發的角色。nginx
如今咱們具體看看怎麼實現代理/轉發,假設要請求的接口爲https://api.yyy.com/data.php
web
文檔:
https://www.npmjs.com/package...npm
如今前端開發通常會在本地使用Node開啓靜態服務器,能夠用http-server
這個包建立一個簡單的靜態服務器,加上選項-P
或--proxy
便可實現接口代理/轉發json
http-server -P https://api.yyy.com
如今爲當前目錄開啓了一個靜態服務器,前端直接請求便可拿到接口數據segmentfault
fetch('data.php').then(console.log)
請求當前data.php
至關於請求https://api.yyy.com/data.php
,而且沒有跨域問題。api
http-server
優勢是簡單快捷,缺點是不夠靈活,且不能自動監聽代碼改動並刷新頁面。跨域BrowserSync
多是更好的選擇。
文檔:https://webpack.js.org/config...
http-server
適合本地寫些簡單頁面、小demo,而咱們開發複雜些的項目,好比基於Vue.js
、React
等來構建項目通常會用到webpack,而且在開發階段使用webpack-dev-server
,這裏只介紹它的代理部分,它的代理實現是基於http-proxy-middleware
封裝。
在webpack.config.js
裏配置
devServer: { // ... proxy: { '/api': { // 若是是匹配全部接口請求能夠用'**' target: 'https://api.vczhan.com', changeOrigin: true, pathRewrite: {'^/api' : ''} // 本地請求中加上了api以區別不一樣接口請求,但真正的接口是沒有的,因此這裏對它重寫 } } }
前端請求
fetch('api/data.php').then(console.log)
這裏請求api/data.php
會轉發到https://api.yyy.com/data.php
。
前端代碼打包後傳到服務器上,須要一個web服務器,這樣才能訪問頁面,這裏選擇nginx
,它既輕便又強大,可配置的規則不少,這裏只展現最簡單的代理配置
server { listen 80; server_name xxx.com location /api/ { proxy_pass https://api.yyy.com/; # 轉發到api.yyy.com # proxy_pass https://api.yyy.com; # 轉發到api.yyy.com/api/ } }
一樣的請求http://xxx.com/api/data.php
會轉發到https://api.yyy.com/data.php
。
雖然也涉及了服務器配置,但基本只要配置一次就好了,通常web頁面的服務器,會給前端同窗權限吧。