1樓：張強張耳朵
要啥API，前端的終極目標就是客戶端直連資料庫，20年前大多數桌面應用就是這樣實現的。
哦，現在換了個名字，叫serverless
2樓：槐槐
前端一般是api的消費者
後端是api的生產者
消費者怎麼去管理生產者的產品呢囧
產品有合適的說明呼叫方式就好了比如用swagger描述介面
3樓：
第一，先跟後端確定API介面的規範，比如：URL規則和返回資料的格式模板。
URL規則：是使用RESTFUL格式，還是自定義規則，我們之前是所有介面都是/api/+專案名+模組名+操作?引數
返回資料模板：一般會有一些基本的統一格式，比如，返回狀態碼（成功，失敗，許可權等不同的狀態碼，告訴前端做不同處理），返回訊息（成功或失敗，需求提示的資訊），返回資料等等，如：
34;code": 134;data൪list൪message": "",
}第二，在約定制定好後，就是如何管理介面資料和介面的文件管理。我之前在網上找了下，沒找到合適的，就自己開發的一套基於NODEJS的系統。
功能說明：
支援視覺化編輯JSON介面資料及介面文件支援GET、POST、PUT、DELETE等請求型別支援指定返回狀態碼，預設200
支援延時返回資料支援mockjs
支援跨域呼叫專案介面支援單個真實介面與模擬介面相互切換（開發過程中某個介面使用模擬資料,當此介面已開發完成後,可將指定介面,通過此服務指向到真實介面上）
使用後基本上解決了前後端配合介面管理的問題
4樓：張衡
推薦題主幾個google 關鍵字，你可以找到很多開源專案或雲服務如果使用 RESTful 介面，google 搜尋1. RESTful API doc
2. RESTful API SDK generator(題主可能想要的是這個)
我們現在使用的 swagger(The World's Most Popular Framework for APIs.)
如果題主是新專案推薦研究 GraphQL
5樓：明理
目前我們的方式：
乙個配置檔案：
const SERVICE_ROUTES = )或其它中間處理：
callServer = function(model_name, action_name, params, callback),
error: function(){ //callback上面方式的優點之一：達到了題主說的集中管理配置的目的。
理想的方式：
1. 首先有乙個wiki，可以查詢所有後台api，這個不多說上面方式的優點之一：解決了後台修改鏈結時，通知前端的問題，前端只需要根據wiki設定好請求需要的模組名引數等等（當然如果模組名或類似的用於標識介面的key改了，那還是得通知前端，但一般情況下，系統會先設計資料庫，資料庫穩定後，模組名什麼的也都應該穩定了）。
上面方式的缺點之一：會增加請求。
ps：如果後台介面路由嚴格按照restful風格，可以看下 用 JSON 構建 API 的標準指南，對應的這裡有各種語言版本的外掛程式：JSON API - Implementations
前端應該信任後端 API 提供的資料嗎？
Ivan 應該信任，不要浪費寶貴的開發時間。前端對後端的不信任，最多也就是質疑下後端是不是合法正常的，其餘的不信任都是多餘的。後端不信任前端的資料是因為只要符合api的規定就能呼叫，容易被非法利用。但是前端不相信後端的話，講道理那也不應該因為後端搞你而導致使用者相關資訊乃至系統完蛋吧？即使多此一舉地...
前後端分離，如何處理前端的異常？
IceWilder 看了前面的回答，我不知道題主表達的是什麼意思。如果是服務端出現異常，返回相應的JSON前端邏輯根據不同的Code之類的去按照自己的邏輯處理就可以了。如果是超時的問題，即比如發乙個ajax請求，不知道是服務端掛掉還是響應未結束，可以設定乙個Timeout,然後一般這麼寫 promi...
JWT Token是該放前端好，還是放後端的cache裡好？
牧歌 你要懂token的乙個校驗過程。後端是簽發乙個token字串傳送給前端，他簽發的乙個過程是需要了乙個金鑰進行加密的。前端必須要傳送這個token回後端，然後才能夠訪問對應介面裡面的資料。token資訊裡面的話可能存著使用者的當前ID，過期時間，還有一些你想放進去的資料，你想放什麼資料進去都可以...