標籤：

前端是如何管理後端提供的API的？

01-04

前端新人正在學習前端，自己寫項目玩。

遇到個問題，前端該如何管理後端的API呢？硬編碼在前端代碼中，這樣不太好吧？還是寫一個統一配置的地方？

前端管理後端api有什麼最佳實踐嗎？ 目前是準備學習vuejs來寫前端

兩個問題要先搞清楚：

怎麼區分「前端」和「後端」，前端指只是瀏覽器端執行的代碼？還是說包括Web伺服器產生HTML的部分？如果是前者，後端就是一切伺服器端；如果是後者，那後端就是在藏在Web伺服器後面的服務。

什麼方面的管理？指的是管理API的地址，還是說管理API介面的輸入輸出格式？還是說其他方面的管理？

上面兩個問題搞清楚了，這個問題就可以回答得更具體，下面我只是根據自己對題主問題的猜想做回答，想到哪寫到哪。

如何管理API的地址？

在不同的環境中，前端（無論如何定義前端）訪問API的地址都可能不同，或者說必定不同。比如，開發某個網站 http://foo.com，在開發環境，API的地址是 https://api.foodev.com/v1/foo ，在產品環境下地址是 https://api.foo.com/v1/foo ，你看，為了區分不同環境，後端API的域名部分就不同，開發環境是 http://api.foodev.com ，產品環境是 http://api.foo.com ，在code中硬編碼肯定不合適。

對於瀏覽器中執行代碼管理API，一個合適的方法是這樣，在產生HTML的Web伺服器中通過讀取一個config（可以是一個config文件，也可以是一個資料庫中的config），獲得當前環境的API域名，以inline script的方式輸出在HTML中，比如產品環境就像這樣。

&
FooConfig.Endpoints = "api.foo.com";
&

在代碼中，讀取FooConfig.Endpoints就獲得域名，加上URL路徑部分，就是最終的API地址。

如何管理API的輸入輸出格式？

API的格式管理很重要，跑通一個API並不難，難的是長時間的管理。

工具上，可以有swagger等工具來描述API，文檔化API，甚至自動生成API，但是，工具只是用來提高我們的效率，不能代替人。如果人的水平高，那怕是用txt也能夠描述好API。

真實情況中，開發API的和使用API的是不同的開發者，甚至是不同的開發團隊，為了防止來回反覆，一個要訣：寫code之前先溝通清楚。一個API有實現的一方，還有使用的一方，一個設計好不好，要考慮雙方的立場，無論是前端或者後端都不能一言堂決定API怎樣。

（先寫到這裡吧，回頭再補充）

分享篇最近寫的文章：《如何處理好前後端分離的 API 問題》 phodal/fe

API 都搞不好，還怎麼當程序員？如果 API 設計只是後台的活，為什麼還需要前端工程師。

作為一個程序員，我討厭那些沒有文檔的庫。我們就好像在操縱一個黑盒一樣，預期不了它的正常行為是什麼。輸入了一個 A，預期返回的是一個 B，結果它什麼也沒有。有的時候，還拋出了一堆異常，導致你的應用崩潰。

因為交付周期的原因，接入了一個第三方的庫，遇到了這麼一些問題：文檔老舊，並且不夠全面。這個問題相比於沒有文檔來說，愈加的可怕。我們需要的介面不在文檔上，文檔上的介面不存在庫里，又或者是少了一行關鍵的代碼。

對於一個庫來說，文檔是多種多樣的：一份 demo、一個入門指南、一個 API 列表，還有一個測試。如果一個 API 有測試，那麼它也相當於有一份簡單的文檔了——如果我們可以看到測試代碼的話。而當一個庫沒有文檔的時候，它也不會有測試。

在前後端分離的項目里，API 也是這樣一個煩人的存在。我們就經常遇到各種各樣的問題：

  • API 的欄位更新了
  • API 的路由更新了
  • API 返回了未預期的值
  • API 返回由於某種原因被刪除了
  • 。。。

API 的維護是一件煩人的事，所以最好能一次設計好 API。可是這是不可能的，API 在其的生命周期里，應該是要不斷地演進的。它與精益創業的思想是相似的，當一個 API 不合適現有場景時，應該對這個 API 進行更新，以滿足需求。也因此，API 本身是面向變化的，問題是這種變化是雙向的、單向的、聯動的？還是靜默的？

API 設計是一個非常大的話題，這裡我們只討論：演進、設計及維護。

前後端分離 API 的演進史

剛畢業的時候，工作的主要內容是用 Java 寫網站後台，業餘寫寫自己喜歡的前端代碼。慢慢的，隨著各個公司的 Mobile First 戰略的實施，項目上的主要語言變成了 JavaScript。項目開始實施了前後端分離，團隊也變成了全功能團隊，前端、後台、DevOps 變成了每個人需要提高的技能。於是如我們所見，當我們完成一個任務卡的時候，我們需要自己完成後台 API，還要編寫相應的前端代碼。

儘管當時的手機瀏覽器性能，已經有相當大的改善，但是仍然會存在明顯的卡頓。因此，我們在設計的時候，儘可能地便將邏輯移到了後台，以減少對於前端帶來的壓力。可性能問題在今天看來，差異已經沒有那麼明顯了。

如同我在《RePractise：前端演進史》中所說，前端領域及 Mobile First 的變化，引起了後台及 API 架構的一系列演進。

最初的時候，我們只有一個網站，沒有 REST API。後台直接提供 Model 數據給前端模板，模板處理完後就展示了相關的數據。

當我們開始需要 API 的時候，我們就會採用最簡單、直接的方式，直接在原有的系統里開一個 API 介面出來。

為了不破壞現有系統的架構，同時為了更快的上線，直接開出一個介面來得最為直接。我們一直在這樣的模式下工作，直到有一天我們就會發現，我們遇到了一些問題：

  • API 消費者：一個介面無法同時滿足不同場景的業務。如移動應用，可能與桌面、手機 Web 的需求不一樣，導致介面存在差異。
  • API 生產者：對接多個不同的 API 需求，產生了各種各樣的問題。

於是，這時候就需要 BFF（backend for frontend）這種架構。後台可以提供所有的 MODEL 給這一層介面，而 API 消費者則可以按自己的需要去封裝。

API 消費者可以繼續使用 JavaScript 去編寫 API 適配器。後台則慢慢的因為需要，拆解成一系列的微服務。

系統由內部的類調用，拆解為基於 RESTful API 的調用。後台 API 生產者與前端 API 消費者，已經區分不出誰才是真正的開發者。

瀑布式開發的 API 設計

說實話，API 開發這種活就和傳統的瀑布開發差不多：未知的前期設計，痛苦的後期集成。好在，每次這種設計的周期都比較短。

新的業務需求來臨時，前端、後台是一起開始工作的。而不是後台在前，又或者前端先完成。他們開始與業務人員溝通，需要在頁面上顯示哪些內容，需要做哪一些轉換及特殊處理。

然後便配合著去設計相應的 API：請求的 API 路徑是哪一個、請求里要有哪些參數、是否需要鑒權處理等等。對於返回結果來說，仍然也需要一系列的定義：返回哪些相應的欄位、額外的顯示參數、特殊的 header 返回等等。除此，還需要討論一些異常情況，如用戶授權失敗，服務端沒有返回結果。

整理出一個相應的文檔約定，前端與後台便去編寫相應的實現代碼。

最後，再經歷痛苦的集成，便算是能完成了工作。

可是，API 在這個過程中是不斷變化的，因此在這個過程中需要的是協作能力。它也能從側面地反映中，團隊的協作水平。

API 的協作設計

API 設計應該由前端開發者來驅動的。後台只提供前端想要的數據，而不是反過來的。後台提供數據，前端從中選擇需要的內容。

我們常報怨後台 API 設計得不合理，主要便是因為後台不知道前端需要什麼內容。這就好像我們接到了一個需求，而 UX 或者美工給老闆見過設計圖，但是並沒有給我們看。我們能設計出符合需求的界面嗎？答案，不用想也知道。

因此，當我們把 API 的設計交給後台的時候，也就意味著這個 API 將更符合後台的需求。那麼它的設計就趨向於對後台更簡單的結果，比如後台返回給前端一個 Unix 時間，而前端需要的是一個標準時間。又或者是反過來的，前端需要的是一個 Unix 時間，而後台返回給你的是當地的時間。

與此同時，按前端人員的假設，我們也會做類似的、『不正確』的 API 設計。

因此，API 設計這種活動便像是一個博弈。

使用文檔規範 API

不論是異地，或者是坐一起協作開發，使用 API 文檔來確保對接成功，是一個「低成本」、較為通用的選擇。在這一點上，使用介面及函數調用，與使用 REST API 來進行通訊，並沒有太大的區別。

先寫一個 API 文檔，雙方一起來維護，文檔放在一個公共的地方，方便修改，方便溝通。慢慢的再隨著這個過程中的一些變化，如無法提供事先定好的介面、不需要某個值等等，再去修改介面及文檔。

可這個時候因為沒有一個可用的 API，因此前端開發人員便需要自己去 Mock 數據，或者搭建一個 Mock Server 來完成後續的工作。

因此，這個時候就出現了兩個問題：

  • 維護 API 文檔很痛苦
  • 需要一個同步的 Mock Server

而在早期，開發人員有同樣的問題，於是他們有了 JavaDoc、JSDoc 這樣的工具。它可以一個根據代碼文件中中注釋信息，生成應用程序或庫、模塊的API文檔的工具。

同樣的對於 API 來說，也可以採取類似的步驟，如 Swagger。它是基於 YAML語法定義 RESTful API，如：

swagger: "2.0"

info:
version: 1.0.0
title: Simple API
description: A simple API to learn how to write OpenAPI Specification

schemes:
- https
host: simple.api
basePath: /openapi101

paths: {}

它會自動生成一篇排版優美的API文檔，與此同時還能生成一個供前端人員使用的 Mock Server。同時，它還能支持根據 Swagger API Spec 生成客戶端和服務端的代碼。

然而，它並不能解決沒有人維護文檔的問題，並且無法及時地通知另外一方。當前端開發人員修改契約時，後台開發人員無法及時地知道，反之亦然。但是持續集成與自動化測試則可以做到這一點。

契約測試：基於持續集成與自動化測試

當我們定好了這個 API 的規範時，這個 API 就可以稱為是前後端之間的契約，這種設計方式也可以稱為『契約式設計』。（定義來自維基百科）

這種方法要求軟體設計者為軟體組件定義正式的，精確的並且可驗證的介面，這樣，為傳統的抽象數據類型又增加了先驗條件、後驗條件和不變式。這種方法的名字里用到的「契約」或者說「契約」是一種比喻，因為它和商業契約的情況有點類似。

按傳統的『瀑布開發模型』來看，這個契約應該由前端人員來創建。因為當後台沒有提供 API 的時候，前端人員需要自己去搭建 Mock Server 的。可是，這個 Mock API 的準確性則是由後台來保證的，因此它需要共同去維護。

與其用文檔來規範，不如嘗試用持續集成與測試來維護 API，保證協作方都可以及時知道。

在 2011 年，Martin Folwer 就寫了一篇相關的文章：集成契約測試，介紹了相應的測試方式：

其步驟如下：

  • 編寫契約（即 API）。即規定好 API 請求的 URL、請求內容、返回結果、鑒權方式等等。
  • 根據契約編寫 Mock Server。可以彩 Moco
  • 編寫集成測試將請求發給這個 Mock Server，並驗證

如下是我們項目使用的 Moco 生成的契約，再通過 Moscow 來進行 API 測試。

[
{
"description": "should_response_text_foo",
"request": {
"method": "GET",
"uri": "/property"
},
"response": {
"status": 401,
"json": {
"message": "Full authentication is required to access this resource"
}
}
}
]

只需要在相應的測試代碼里請求資源，並驗證返回結果即可。

而對於前端來說，則是依賴於 UI 自動化測試。在測試的時候，啟動這個 Mock Server，並藉助於 Selenium 來訪問瀏覽器相應的地址，模擬用戶的行為進行操作，並驗證相應的數據是否正確。

當契約發生髮動的時候，持續集成便失敗了。因此相應的後台測試數據也需要做相應的修改，相應的前端集成測試也需要做相應的修改。因此，這一改動就可以即時地通知各方了。

前端測試與 API 適配器

因為前端存在跨域請求的問題，我們就需要使用代理來解決這個問題，如 node-http-proxy，並寫上不同環境的配置：

這個代理就像一個適配器一樣，為我們匹配不同的環境。

在前後端分離的應用中，對於表單是要經過前端和後台的雙重處理的。同樣的，對於前端獲取到的數據來說，也應該要經常這樣的雙重處理。因此，我們就可以簡單地在數據處理端做一層適配。

寫前端的代碼，我們經常需要寫下各種各樣的：

if(response response.data response.data.length &> 0){}

即使後台向前端保證，一定不會返回 null 的，但是我總想加一個判斷。剛開始寫 React 組件的時候，發現它自帶了一個名為 PropTypes 的類型檢測工具，它會對傳入的數據進行驗證。而諸如 TypeScript 這種強類型的語言也有其類似的機制。

我們需要處理同的異常數據，不同情況下的返回值等等。因此，我之前嘗試開發 DDM 來解決這樣的問題，只是輪子沒有造完。諸如 Redux 可以管理狀態，還應該有個相應的類型檢測及 Adapter 工具。

除此，還有一種情況是使用第三方 API，也需要這樣的適配層。很多時候，我們需要的第三方 API 以公告的形式來通知各方，可往往我們不會及時地根據這些變化。

一般來說這種工作是後台去做代碼的，不得已由前端來實現時，也需要加一層相應的適配層。

小結

總之，API 使用的第一原則：不要『相信』前端提供的數據，不要『相信』後台返回的數據。

讓API介面明了好用是API的責任，不是前端的責任。提供文檔是API的責任，詳細的參數說明，返回格式說明等等。前端是API的用戶，愛怎麼用怎麼用，hard code不總是垃圾，你放配置文件了，整個代碼庫也只有一個地方在用（這點點好處不值得討論），如果有多個地方在用，只說明你分層和模塊化沒有做好。

你煞有介事地管理代碼的細節，不等於在管理API。

同學你聽過orm嘛？

如果您不是重量級或工業級的團隊，您只希望輕鬆快捷的管理 api，歡迎來了解 amWiki 輕文庫

amWiki 除了作為個人使用(https://www.zhihu.com/question/27027157)，還可以作為團隊的介面文檔來使用
作為介面文檔使用的時候，不單單只是 url、類型、請求、響應 的描述，還可以在頁面直接發起 ajax 請求，顯示真實響應內容
事實上，目前我所在的工作團隊，已經使用 amWiki 累積了近千篇的 api 介面文檔，而且依賴 amWiki 介面文檔進行前後端並行開發，一直以來都反映良好

點擊右上角 [測試介面] 彈出測試面板：
（「測試介面」的功能，只有開啟了測試模塊，並且當前文檔能識別為介面文檔時才會出現）

點擊「發送Ajax」可以真實發送ajax測試介面並查看實際響應內容，可以手動修改值、臨時增加新參數，以及給全文庫所有介面增加全局參數等等
實現這樣一篇介面文檔，僅需要包含如下 Markdown 文本內容

本文內容的演示：amWiki 通用 API 介面文檔示範

API不需要前端管理，前端維護的是代碼的可讀性。

1、封裝post、get、delete等方法；

2、在你需要調用ajax的時候調用該方法即可。

寫代碼之前, 前後端的數據格式是已經定下來了的, 此後前端用的數據都是些mock數據.

例如: thx/RAP .

之前一直也很疑惑，後來用上了GraphQL後這個問題直接解決了。

GraphQL是前端管理的Node伺服器中的非常有益的補充，等於給了前端一個穩定的，由前端定義的數據來源。前端可以重新命名和定義一些API（可能前後端叫法不太一致），還可以在收到後端的初次相應後，從中端直接往後請求某些數據的詳細信息（eg userId =&> user），節省一次round trip的同時，對API返回的內容會有更充足的把握。而且，每次請求會得到的內容也由前端控制，比較隨心所欲。

另外，雖然文檔是絕對主流，但人總是對自己寫過一遍的東西記得最清楚。用了這個之後，我只要查一次文檔，把他們寫進GraphQL query list里，就可以用我自己定義的這些query而不是直接調用API了。實測開發效率確實有提高。。

@程墨Morgan

用相對路徑不就避免了host不一致的問題了？test staging production 分別部署代碼庫。本地開發的時候，就做個代理層唄！

至於api的溝通，

簡單的wiki足夠了。 變化的時候，必須相互通知一下。

牛逼的 apiary 也應該足夠。

之前做過一套簡易的api管理，簡述以下。

在寫api的時候，明確在注釋上寫上該api的信息。

然後由程序自動讀取代碼注釋。 如有變動。立刻發送email給相關同事。並且配置了相應的查詢界面。 以及界面化調試 修改 mock等。

完美吧！！ 可是發現公司用的人並不多，人是很懶的，他們往往更喜歡一個東西-- WIKI

所以說 最有效率的api管理就是 WIKI+人的溝通

/*
* @type GET
* @param
* id String 用戶id
* xxx String 用戶xxx
* @return
* body.name String 用戶姓名
* body.age Int 用戶年齡
*/

// === 生成的json

{
url : "/user/info"
method : GET,
params : {
id : {
type : String,
desc : 用戶id
}
},
res : [
{
success : true,
body : {
name : {
type : String,
desc : 用戶姓名
}
}
},
{
success : false,
info : "Error msg"
}
]
}

看了題主在各個回答下的評論，感覺題主你問的好像和大多數答主的理解不太一樣啊...

首先如果是單純管理api，這個方式很多，可以讓後端同學維護一份文檔，也可以中間封一層ORM，或者用graphql做個中間層（這種我沒用過）。一般來說最簡單得就是維護一個wiki，寫上介面名稱，方法，參數列表等等。

但是我看題主的回復中提到了修改前端的代碼，就有點奇怪了，這種配置性的東西一般來說不屬於api的管理，比如常見的baseUrl，或者test-token之類的，直接在前端維護一個hash就完了。這個和api的維護又是另外一種東西了，不知道題主到底是什麼意思呢？

現在這樣的工具越來越多了，質量良莠不齊，推薦下我司開發的 NEI 介面管理平台：https://nei.netease.com，介紹文章請戳：NEI 介面管理平台 - 知乎專欄，主要功能有：

1. 不只是 api 文檔管理，NEI 的視角是整個項目，更符合實際開發情況

2. 介面 Mock Server，方便前後端並行開發，極大地提高了生產力

3. 介面測試，後端開發自測，測試人員錄入測試用例，全方位保證介面交付質量

4. 工程規範，最大限度地自定義項目的初始化目錄結構，方便新項目啟動，還有其他更多功能等你來挖掘

分享下去哪兒的經驗，我們自研了 yapi介面管理平台 ，前端基於這個規範生成 mock數據，後端根據這個規範調試和測試介面

前端的童鞋可以看看我寫的這篇文章：前端模擬介面數據（mock）實踐

越來越多的公司將前端和後端徹底分離，以便能夠支持後端一套介面，提供給 web, ios, android 使用，大大提高了開發的效率。但與此同時，也帶來了前端 ui 依賴後端數據的問題，在後端的介面沒有開發完成之前，前端需要根據介面定義的規範模擬介面數據。這個問題看似簡單，但實際上在開發過程中，會是一個比較頭疼的問題。

以往的做法

有基於前端和後端兩種做法，前端大多數都是在業務代碼裡面先根據後端的介面定義，寫一套模擬數據，也有基於 mockjs 通過攔截 xhr 方式。後端大多是先寫一套測試數據的介面，提供給前端調用，等介面開發完成之後，在切換過來。無論是哪一種方式，都不可避免的有以下問題：

1.影響了業務的代碼，經常能見到下面這種代碼,注釋了原有的代碼邏輯，改成測試的模擬數據

getUserData = (uid) =&>{
//return axios.get("/api/user/" + uid);
return new Promise((resolve, reject)=&> {
setTimeout(()=&>{
return resolve({
data: {
errcode: 0,
data: {
uid: 1,
username: "tom"
}
}
})
}, 100)
})
}

2. 後端介面數據結構發生變動，增加欄位、修改欄位名稱了，無法及時反饋給前端開發者，更新滯後。

3. 不容易模擬複雜情況，例如介面響應時間，生成各類模擬數據，如郵箱、手機號等等

{
email: "abc@163.com",
phone: "18000803800"
}

4. 在實際的開發過程中，我們不僅需要模擬正常情況下 UI，還需要模擬數據出錯，數據為空時的 UI。

去哪兒前端介面 Mock 實踐

我們研發了 YApi介面管理平台 管理我們前端介面數據的模擬, 只需要前後端去維護在 YApi 平台定義的響應數據，就可以生成需要的模擬數據，下面這段代碼就是定義的生成數據模板：

{
"errcode": 0,
"errmsg": "@string",
"data": {
"type":"@pick(1,2,3)",
"list|1-10": [{
"uid": "@id",
"username": "@name"
}]
}
}

可生成如下的模擬數據：

{
"errcode": 0,
"errmsg": "^*!SF)R",
"data": {
"type": 2,
"list": [
{
"uid": "370000200707276255",
"username": "Ruth Clark"
},
{
"uid": "650000200211185728",
"username": "Anthony Martin"
},
{
"uid": "370000199201143855",
"username": "Laura Rodriguez"
},
{
"uid": "610000198704072775",
"username": "Anthony Perez"
}
]
}
}

使用方法

介面預覽頁面可看到 mock 地址，通過直接調用或者伺服器代理方式，就可獲取到隨機生成的數據，不會影響業務邏輯代碼

高級 Mock

基礎的 Mock 工具已經能滿足大部分的需求了，但有些複雜場景是無法實現的。例如：當我做一個數據列表頁面，需要測試某個欄位在各種長度下的 ui 表現，還有當數據為空時的 ui 表現。YApi 提供了期望和自定義腳本的功能。

Mock 自定義腳本

自定義腳本可根據請求的參數，cookie 信息，使用 js 腳本自定義返回的數據，推薦基於 cookie 生成不同的測試數據，這樣就能通過控制瀏覽器 cookie 值，獲取到不一樣的模擬數據。

if(cookie._type == "error"){
mockJson.errcode = 400;
}

if(cookie._type == "empty"){
mockJson.data.list = [];
}

Mock 期望

期望就是需要根據不同的請求參數、IP 返回不同的 HTTP Code、HTTP 頭和 JSON 數據，Mock 期望主要用於 ui 的自動化測設和後端介面自動化測試。

後記

YApi介面管理平台 已在去哪兒公司內部大面積使用，獲得了很多贊，為了讓 YApi 能夠服務更多小夥伴和使 YApi 變的更好，現已經開源到 https://github.com/ymfe/yapi，歡迎大家使用和提出寶貴的意見。

最簡單的方式是寫一份技術文檔，放到大家都能編輯閱讀的地方 wiki，列出所有API的 url、類型、請求、響應

然後用什麼找什麼就行了

我們目前在用Vue做一個後台項目，我來談談我目前用的方案吧。

我用的方式比較簡單粗暴。

首先就是約定後端返回的數據模板格式，創建api文件夾

然後新建了urlType.js文件,

內容基本如下：

export const getList = [
{
name: "getAllUser",
url: "user/all"
}
]

export const postList = [
{
name: "addUser",
url: "user/save"
},
]

export const deleteList = [
{
name: "deleteUser",
url: "user/delete"
}
]

...

然後我創建了一個Api類，

import * as URL from "./urlType.js"

class Api {
constructor () {
this.http
}

/**
* 作為Vue插件進行安裝，掛載到Vue.prototype
* @param {Object} Vue Vue
* @param {String} baseUrl 配置項
* @return {}
*/
install (Vue, baseUrl) {
Vue.http.options.root = options
this.http = Vue.http
Vue.prototype.$api = this
}
}

URL.getList.forEach((getObj) =&> {
Api.prototype[getObj.name] = function (queryStr = "") {
return new Promise((resolve, reject) =&> {
this.http.get(getObj.url + queryStr).then(res =&> {
resolve(res)
}, reject)
})
}
})

export default Api()

再然後在入口文件main.js中

import Vue from "vue"
import VueResource from "vue-resource"
import Api from "./api"

ue.use(VueResource)
Vue.use(Api, "http://192.168.1.101:8080")

new Vue({
el: "#app",
template: "&",
components: { App }
})

這樣我們在任何.vue文件中就可以以 this.$api.getAllUser().then().catch() 的方式調用api了。

以上就是我目前的做法，好處是我們不會再在任何.vue或.js文件中寫url地址啦，並且我們的url得到了統一的管理，在.vue文件中也不需要在import service（之前採用過類似的方案是把api請求單獨抽離成service，不過每次用到都需要引入，因為覺得太麻煩就換成了目前這種簡單粗暴的方式 = = ）

目前我們的方式：

一個配置文件：
const SERVICE_ROUTES = {
model_name: [
"action_name", ["develop_mode_url", "get"], ["production_mode_url", "get"],...
]
}
如：
const SERVICE_ROUTES = {
user: [
"list", ["/test/user/list", "get"], ["/api/user/list", "get"],...
],
...
}
調用：
callServer("user", "list", { page:1, size: 6 })或其它

中間處理：
callServer = function(model_name, action_name, params, callback){
var config = SERVICE_ROUTES[model_name][0];//此處省略根據action_name匹配過程
var url_config = CURRENT_MODE === "develop" ? config[0] : config[1];
var url = url_config[0], method = url_config[1];
$.ajax({
url: url,
type: method,
data: params,
success:function(){ //callback },
error: function(){ //callback }
});
};

上面方式的優點之一：達到了題主說的集中管理配置的目的。

上面方式的缺點之一：後台修改介面鏈接時，得通知前端。

理想的方式：

1. 首先有一個wiki，可以查詢所有後台api，這個不多說

2. 同時後台提供一個介面獲取後台介面列表（這裡也可以展開來討論，比如介面太多，可以傳入參數如模塊名僅獲取該模塊下所有介面列表等）

上面方式的優點之一：解決了後台修改鏈接時，通知前端的問題，前端只需要根據wiki設置好請求需要的模塊名參數等等（當然如果模塊名或類似的用於標識介面的key改了，那還是得通知前端，但一般情況下，系統會先設計資料庫，資料庫穩定後，模塊名什麼的也都應該穩定了）。

上面方式的缺點之一：會增加請求。

ps：如果後台介面路由嚴格按照restful風格，可以看下 用 JSON 構建 API 的標準指南，對應的這裡有各種語言版本的插件：JSON API - Implementations

丁香園開源的 mock 系統值得自己搭建一套，DXY-F2E/api-mocker 地址

前端一般是api的消費者

後端是api的生產者

消費者怎麼去管理生產者的產品呢 囧

產品有合適的說明 調用方式就好了 比如用swagger描述介面

第一，先跟後端確定API介面的規範，比如：URL規則和返回數據的格式模板。

URL規則：是使用RESTFUL格式，還是自定義規則，我們之前是所有介面都是/api/+項目名+模塊名+操作?參數

返回數據模板：一般會有一些基本的統一格式，比如，返回狀態碼（成功，失敗，許可權等不同的狀態碼，告訴前端做不同處理），返回消息（成功或失敗，需求提示的信息），返回數據等等，如：

{
"code": 1,
"data": {
"list": [],
},
"message": "",
}

第二，在約定製定好後，就是如何管理介面數據和介面的文檔管理。我之前在網上找了下，沒找到合適的，就自己開發的一套基於NODEJS的 系統。

WEB版的數據模擬及文檔管理系統 ：flftfqwxf/mock-server

功能說明：

支持可視化編輯JSON介面數據及介面文檔

支持GET、POST、PUT、DELETE等請求類型

支持指定返回狀態碼，默認200

支持延時返回數據

支持mockjs

支持跨域調用項目介面

支持單個真實介面與模擬介面相互切換（開發過程中某個介面使用模擬數據,當此介面已開發完成後,可將指定介面,通過此服務指向到真實介面上）

使用後基本上解決了前後端配合介面管理的問題

阿里的RAP，誰用誰知道。

有介面文檔，不用擔心

推薦閱讀：

※如何使自己編寫的程序更靠譜(Robust)？
※js原型鏈與lua元表的異同？
※產品經理如何在設計產品時避免給開發挖坑?
※前端開發js函數式編程真實用途體現在哪裡？
※怎麼評價Vue.js2.5以後要大力加強對TypeScript和VSCode的支持？

TAG:前端開發 | JavaScript | 前端工程師 | Vuejs |