我們的框架也是前後臺分離。後端介面的多少應該根據業務合理劃分，而不是誰覺得多不方便，開發不能只從方便入手。整體上介面設計的多少應從以下幾個方面考慮：

1、介面粒度的細分考慮職責單一，還得考慮多個操作是否應該在同一事物中，若在同一事物中介面的粒度可設計大一點。

2、介面的合併問題，當有多次請求不同介面而返回資料量又不大的時候可酌情將介面進行合併。

3、介面的拆解問題，當一次返回資料量過大導致傳輸慢的時候，根據業務得拆成多個介面，並要分析哪些資料先請求，哪些後請求。

5、介面停止服務問題，舉個例子，在618，雙11時很多商品有促銷活動（提供的介面），當過了這兩天，完全可以把此類服務停止減少負荷。

以上是我從實際專案角度做的分析，希望幫助到你，具體到專案中可深入探討。

這是一個非常好的問題，作為一名IT從業者，我來回答一下。

首先，介面作為連線前後端的重要橋樑，在整個程式開發過程當中起到了非常重要的作用，介面本身的設計也體現出了程式設計師的能力和水平，所以在設計介面的過程中，也會逐漸獲得開發能力上的提升。

介面設計的優劣往往取決於三方面因素，其一是抽象程度；其二是程式的模組化管理；其三是程式的開發基礎（平臺），這與具體的技術選型有比較直接的關係。

對於前端開發人員來說，介面一定是越少越好，一方面在進行介面測試的過程中比較方便，工作量也比較少，另一方面在使用的過程中也比較簡單，未來在進行升級修改時也比較容易實現。實際上，對於功能比較複雜的業務平臺來說，如果介面的設計過於繁多，也確實會給前端開發人員帶來很多的困惑。

按照歷史經驗來看，在進行開發團隊迭代的過程中，很多介面都會面臨重構的問題，這往往會為前端開發人員帶來更多的工作量，很多傳統的程式碼也需要重構。而要想避免類似的問題，通常就需要介面設計人員能夠充分考慮到向下相容的問題。

在前端開發人員對於後端介面設計提出質疑的時候，往往是後端平臺的介面設計已經出現了眾多的冗餘，相關介面沒有做好規劃，此時介面設計人員應該儘量少寫“補丁介面”，儘量在已有的介面基礎上進行升級，這個工作量雖然會大一些，但是對於維護系統的抽象程度和模組化都有比較現實的意義，不至於導致系統未來的維護難度越來越大。

對於介面設計人員來說，如果系統的模組規劃出現了問題，或者是抽象程度不足（過度），那麼應該及時與開發團隊進行溝通，同時為前端開發人員做好規劃，也需要與前端開發人員進行溝通，以便於讓前端開發人員為後續的升級做好準備。

最後，任何技術問題的出現都需要進行溝通，而溝通的目的就是為了達成共識。

從題主的問題闡述來看，想必應該是搞後端的吧，同行見同行，兩眼淚汪汪。作為同行，深有感觸，但是在這裡我不會力挺同行，而是要告訴你們兩句話，第一句話是：有理走遍天下，無理寸步難行。第二句話是：本是同根生，相煎何太急。

從問題描述來看，再加上我個人的一些經驗，我感覺前端應該是一位“大佬”，經驗豐富，所以才會嫌棄你介面分太多，不然他肯定會本本分分地把所有介面一一對接完畢，當然也許他對業務不是十分地清楚，只是站在自身的角度考慮，怎麼方便怎麼來，所以透過問題分析歸納為兩點：

1、介面確實太多了。

2、介面不多，是前端不瞭解業務，不知道介面的具體作用。

分析了問題的癥結所在，那麼我們就要具體問題具體解決，這才是做好事情的唯一途徑，不然兩兄弟互相嫌棄和抱怨，到最後只會搞得兩敗俱傷。

1、針對介面確實太多的問題

人非聖賢，孰能無過，其實這也不是錯誤，而是存在可以最佳化的空間，有的可以一次性返回的資料就沒必要讓前端調多次介面，這樣不僅費時費力，還影響效率，所以如果確實是此問題的話，題主就應該檢查相關的介面資訊返回，爭取能夠減少前端的呼叫次數，具體操作有：

如果是單表查詢，沒有前端想要的資訊，如果有必要的話可以在查詢的那張表裡加上想要的欄位。比如：一張訂單表orders，但是前端可能想要的暱稱在這張表裡沒有，此時就可以在表裡加上nickname的欄位，當然並不是前端需要什麼就加什麼，而之所以加某個欄位，是因為覺得某個欄位是有必要的，加上去更方便一些。

如果是多表查詢，沒有前端想要的資訊，那就可能要在返回的DTO里加上想要的資訊。比如：一張訂單表orders，一張使用者表users，此時DTO返回給前端的資訊裡沒有暱稱，而暱稱在users裡面已經有了，所以這個時候就只要在DTO里加上nickname就好了。

等本地驗證好，更新了服務之後，就可以叫前端重新再調一下介面驗證就好了，不用感覺尷尬為難或者怎麼的，其實這樣的事在哪個公司都是屢見不鮮的事。

2、針對前端不瞭解業務理解錯誤的問題

如果確實不是後端介面的問題，而是因為前端不瞭解全域性流程或需求而導致的認知差，這個時候就不需要調整介面，而是耐心地跟前端解釋清楚。

其實在我跟前端對接的過程中，很多時候也確實遇到很多抓狂的事，有的我們看似很簡單的東西，甚至文件裡都寫的清清楚楚，可就是還要來問，但是沒辦法，還是得耐心告訴對方怎麼調，因為此時的你們就是同一條船上的螞蚱，只有齊心協力把介面調通了，才算完成了任務。

經過以上的分析，我想題主應該知道怎麼做了吧，如果確實是後端介面的問題，那我們就要自省，進行改進和最佳化，如果不是後端介面的問題，那我們就要解釋和指導，前後端本是一體，沒必要煩憂和抱怨，大家共同把事情做好才是最終目標。