雷鎬
我們的框架也是前後臺分離。後端接口的多少應該根據業務合理劃分，而不是誰覺得多不方便，開發不能只從方便入手。整體上接口設計的多少應從以下幾個方面考慮：
1、接口粒度的細分考慮職責單一，還得考慮多個操作是否應該在同一事物中，若在同一事物中接口的粒度可設計大一點。
2、接口的合併問題，當有多次請求不同接口而返回數據量又不大的時候可酌情將接口進行合併。
3、接口的拆解問題，當一次返回數據量過大導致傳輸慢的時候，根據業務得拆成多個接口，並要分析哪些數據先請求，哪些後請求。
4、接口重複問題，比如PC應用和移動應用用到同一組數據，後臺針對PC和移動端應用開發了兩個接口，這種情況下可以刪除一個接口。
5、接口停止服務問題，舉個例子，在618，雙11時很多商品有促銷活動（提供的接口），當過了這兩天，完全可以把此類服務停止減少負荷。
以上是我從實際項目角度做的分析，希望幫助到你，具體到項目中可深入探討。
林時變量
這是一個非常好的問題，作為一名IT從業者，我來回答一下。
首先，接口作為連接前後端的重要橋樑，在整個程序開發過程當中起到了非常重要的作用，接口本身的設計也體現出了程序員的能力和水平，所以在設計接口的過程中，也會逐漸獲得開發能力上的提升。
接口設計的優劣往往取決於三方面因素，其一是抽象程度；其二是程序的模塊化管理；其三是程序的開發基礎（平臺），這與具體的技術選型有比較直接的關係。
對於前端開發人員來說，接口一定是越少越好，一方面在進行接口測試的過程中比較方便，工作量也比較少，另一方面在使用的過程中也比較簡單，未來在進行升級修改時也比較容易實現。實際上，對於功能比較複雜的業務平臺來說，如果接口的設計過於繁多，也確實會給前端開發人員帶來很多的困惑。
按照歷史經驗來看，在進行開發團隊迭代的過程中，很多接口都會面臨重構的問題，這往往會為前端開發人員帶來更多的工作量，很多傳統的代碼也需要重構。而要想避免類似的問題，通常就需要接口設計人員能夠充分考慮到向下兼容的問題。
在前端開發人員對於後端接口設計提出質疑的時候，往往是後端平臺的接口設計已經出現了眾多的冗餘，相關接口沒有做好規劃，此時接口設計人員應該儘量少寫“補丁接口”，儘量在已有的接口基礎上進行升級，這個工作量雖然會大一些，但是對於維護系統的抽象程度和模塊化都有比較現實的意義，不至於導致系統未來的維護難度越來越大。
對於接口設計人員來說，如果系統的模塊規劃出現了問題，或者是抽象程度不足（過度），那麼應該及時與開發團隊進行溝通，同時為前端開發人員做好規劃，也需要與前端開發人員進行溝通，以便於讓前端開發人員為後續的升級做好準備。
最後，任何技術問題的出現都需要進行溝通，而溝通的目的就是為了達成共識。
我從事互聯網行業多年，目前也在帶計算機專業的研究生，主要的研究方向集中在大數據和人工智能領域，我會陸續寫一些關於互聯網技術方面的文章，感興趣的朋友可以關注我，相信一定會有所收穫。
如果有互聯網、大數據、人工智能等方面的問題，或者是考研方面的問題，都可以在評論區留言，或者私信我！
IT人劉俊明
從題主的問題闡述來看，想必應該是搞後端的吧，同行見同行，兩眼淚汪汪。作為同行，深有感觸，但是在這裡我不會力挺同行，而是要告訴你們兩句話，第一句話是：有理走遍天下，無理寸步難行。第二句話是：本是同根生，相煎何太急。
問題分析
從問題描述來看，再加上我個人的一些經驗，我感覺前端應該是一位“大佬”，經驗豐富，所以才會嫌棄你接口分太多，不然他肯定會本本分分地把所有接口一一對接完畢，當然也許他對業務不是十分地清楚，只是站在自身的角度考慮，怎麼方便怎麼來，所以通過問題分析歸納為兩點：
1、接口確實太多了。
2、接口不多，是前端不瞭解業務，不知道接口的具體作用。
解決問題
分析了問題的癥結所在，那麼我們就要具體問題具體解決，這才是做好事情的唯一途徑，不然兩兄弟互相嫌棄和抱怨，到最後只會搞得兩敗俱傷。
1、針對接口確實太多的問題
人非聖賢，孰能無過，其實這也不是錯誤，而是存在可以優化的空間，有的可以一次性返回的數據就沒必要讓前端調多次接口，這樣不僅費時費力，還影響效率，所以如果確實是此問題的話，題主就應該檢查相關的接口信息返回，爭取能夠減少前端的調用次數，具體操作有：
如果是單表查詢，沒有前端想要的信息，如果有必要的話可以在查詢的那張表裡加上想要的字段。比如：一張訂單表orders，但是前端可能想要的暱稱在這張表裡沒有，此時就可以在表裡加上nickname的字段，當然並不是前端需要什麼就加什麼，而之所以加某個字段，是因為覺得某個字段是有必要的，加上去更方便一些。
如果是多表查詢，沒有前端想要的信息，那就可能要在返回的DTO里加上想要的信息。比如：一張訂單表orders，一張用戶表users，此時DTO返回給前端的信息裡沒有暱稱，而暱稱在users裡面已經有了，所以這個時候就只要在DTO里加上nickname就好了。
等本地驗證好，更新了服務之後，就可以叫前端重新再調一下接口驗證就好了，不用感覺尷尬為難或者怎麼的，其實這樣的事在哪個公司都是屢見不鮮的事。
2、針對前端不瞭解業務理解錯誤的問題
如果確實不是後端接口的問題，而是因為前端不瞭解全局流程或需求而導致的認知差，這個時候就不需要調整接口，而是耐心地跟前端解釋清楚。
其實在我跟前端對接的過程中，很多時候也確實遇到很多抓狂的事，有的我們看似很簡單的東西，甚至文檔裡都寫的清清楚楚，可就是還要來問，但是沒辦法，還是得耐心告訴對方怎麼調，因為此時的你們就是同一條船上的螞蚱，只有齊心協力把接口調通了，才算完成了任務。
結束語
經過以上的分析，我想題主應該知道怎麼做了吧，如果確實是後端接口的問題，那我們就要自省，進行改進和優化，如果不是後端接口的問題，那我們就要解釋和指導，前後端本是一體，沒必要煩憂和抱怨，大家共同把事情做好才是最終目標。
