杭素文
肯定是不合理的，通常在前後端合作開發的時候，或者兩個系統要做服務調用的時候，首先是要確認接口文檔。現在我負責的一個項目，只提供查詢服務，當我們在做一個新接口的時候，通常會提供這麼幾個時間點：提供接口文檔的時間，聯調測試的時間和正式提測的時間，可以看到接口文檔肯定是要第一時間提供的。
在早期的項目開發中，開發人員要負責前端加後端的開發，一個人負責一個模塊或者一個需求的時候，通常是需要從前端管到後端的，而前後端分離架構的出現，意味著開發人員的分離，每個開發人員會負責某一個領域的事情；而先確定接口文檔最重要的一點，就是可以讓所有的前端開發和後端開發並行工作，不然的話，就可能項目前期，前端開發人員閒著沒事兒做，因為要等接口文檔，而項目後期後端開發又沒事兒做，因為要等前端開發好了才能提測。
所以，一定要文檔確認，雙方並行開發，再在一個時間點聯調測試；系統和系統之間調用的場景也類似，也是要確認文檔後，兩個系統並行開發，在規定時間點開始聯調測試。
在接口文檔確認之後，建議前後端兩方、或系統和系統兩方的開發人員組織評審，兩方認為文檔沒有什麼問題後再進行開發，如果在開發過程中有不合理的地方，再對接口進行微調。
再說說我們項目，因為我們不是前後端分離的場景，只是對外提供服務，所以基本上都是服務提供方確定文檔，不需要再做什麼評審，當然在接口確認過程中也有幾點要注意：
1. 遵守接口規範，如果公司有接口規範的話就最好了，可以節省很多不必要的麻煩；如果公司沒有制定統一的規範，也至少在項目組內製定自己的規範。
2. 接口參數見名知意，我們對於 DTO 中的字段名稱都是有統一規範的，比如性別就都叫 gender，如果是老項目的話，數據庫中的表結構不容易修改，比如姓名字段已經起名叫做 sex 了，也建議在代碼中對 Model/VO 轉一次到 DTO。
3. 接口文檔確認後，儘量不要做修改，這就意味著你在正式開發前，就要做評估和設計。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
一個非常好的問題，我是工作多年的Web應用架構師，來回答一下這個問題。歡迎關注我，瞭解更多IT專業知識。
後端給出接口文檔太晚，也合理也不合理，要看具體情況，總有解決方法，我來說一下我的觀點。
不合理：成熟的技術團隊，重視功能設計，在動手寫代碼之前已經有了完整的技術文檔和功能定義，甚至在TDD測試驅動開發模式中，測試數據已經準備就緒，那麼這時接口文檔不管寫沒寫，接口邏輯都是已經確定的，整理出來是水到渠成。
合理：多存在於早期小型創業公司，主觀客觀原因都有。
- 先說主觀原因。趕進度、沒時間、懶得寫，甚至開發前都沒做仔細的設計，邊做邊改，這些原因普遍存在，也實在沒啥好辦法。
- 客觀原因，需求在變，功能跟著變，接口也要變，那麼如果寫了文檔，理所當然也要更新維護啊？我的天哪。
有解決方法嗎？建議試試：
1，Swagger接口文檔，將文檔融合到代碼中，讓維護文檔和修改代碼整合為一體，使得修改代碼邏輯的同時方便的修改文檔說明。
2，Postman接口測試工具，導入導出JSON文件，高效團隊協作。Postman支持各種請求方式和配置環境變量，並對返回結果進行測試校驗，支持批量自動化運行，可以和自動構建系統集成。
急速馬力快de源碼客
我覺得不太合理。說一下我的觀點...
在需求已經定的情況下，後端開發應該優先根據原型圖將接口定義(後續可以適當修改)好，並且提供對應的接口的文檔。然後在前後端同學對提供的接口文檔沒有異議的情況下，可以並行開發。這樣在字段名都定義好的前提下，前後端同學就不會在聯調的時候互相甩鍋了…這樣也可以提高開發效率，避免後端同學閉門造車。同時也會增進同事之間的默契。還有就是如果後續前後端同時開發的時候，發現接口參數需要變動的話。也可以及時修改，避免重複造輪子。
事情都是要做的，要找到一個省心省力的辦法解決問題。多為跟自己聯調的同學考慮，給予對方最大幫助。
J小勁
肯定是不合理的，項目的整個研發流程還有前端還有測試，還有其他的後端人員，不可能通過口口相傳來進行接口說明，所以必須要寫接口文檔。
從團隊合作
如果項目是前後端分離架構的，那一定涉及到前端開發人員還有測試人員，還有其他後端開發人員，這些人都有需要去了解接口到的實現，如果不寫接口文檔，那這些人怎麼辦，如何瞭解到接口的設計，地址是什麼，傳參是什麼，參數的長度、類型，是否是必傳的，總不能天天問開發，如果是這樣那就是給自己挖了一個大坑，優秀的開發是不會這樣做的。即使不是前後分離，測試也沒有，都由研發自己負責，那隨著不斷的迭代，接口越來越多，當需要去了解以前的接口設計時，就得回去看代碼，自己也會瘋掉，遠不如看文檔來的清晰明瞭。清晰明瞭的接口文檔有助於團隊之間的合作，其實也會為自己省去不少時間。
傳承
互聯網公司的流動性大，這是眾所周知的，隨著人員的流動，本來做這個接口的人員離職了，新接手的同學要想了解以前的接口，只能看代碼，還是痛苦。再有新來的前端同學和測試同學想要了解接口，怎麼辦。
個人
程序員最討厭的四件事情，不喜歡看別人的代碼，不喜歡別人的代碼沒有註釋，不喜歡自己寫註釋，不喜歡自己寫文檔。看似簡單的接口文檔，其實體現的是研發人員的接口設計能力，當輸出到的接口文檔不會被人挑刺，不會被問死，那說明設計能力已經不錯了。而且寫出優秀的文檔本身也是對自己寫作能力的一種鍛鍊，何樂不為呢。
質量
接口文檔體現的是研發對這個接口實現的設計，當對業務需求、前後端交互有足夠的理解，才能寫出優秀的文檔，這本身也是質量管理的非常重要的一個步驟。
總結
需求研發的過程每個組都會輸出自己的文檔，產品要輸出合理詳細的需求文檔，研發輸出優秀的設計文檔和接口文檔，測試輸出完善的測試方案和覆蓋全面的測試用例，各個環節都儘自己的努力輸出該有的東西，相信產品的上線質量會好很多。
測試軒
後出文檔的人應該沒怎麼做過前端，不理解為什麼前後分離以及前後分離的優勢，更不知道該如何協作，只是單純認為出接口是個多餘的勞動吧，我在公司推廣了yapi，後端竟然還是還是不願意寫，每次該提測了，接口文檔剛剛寫好，其實就是postman請求然後貼到文檔裡，前端開發完全憑經驗靠蒙，提測前改屬性名，還得自測半天，最後還給前端提一些參數錯誤的bug，以後還是前後端一起搞比較好，項目劃分
飆車族nbn
合不合理要看開發模式，前後端分離的，而且定義好了請求體和返回體，不合理，而且你要等全端要接口，說明你也不是一個好前端。要是後段驅動模式，就是說只給出業務需求的由後端實現的，那麼很正常，畢竟後端為主，而且後段需要一個完整的業務流程接口開發完才能給到前端，畢竟數據是一個完整的流程，後段還要造數據接口才能調通
碼小卒
不合理。文檔永遠是很重要的,降低溝通成本,提高開發效率:
- 可以使用swagger:
http://www.zhikestreet.com/content/p/29.html
- EOLINker: http://www.zhikestreet.com/content/p/6.html
頂級碼農
這tm一點都不合理，這樣前端開發就必須等他們搞完，這不是浪費了時間嗎。
應該先定接口，然後各自開發。
古月大叔
這是個邏輯的問題。一般後端都是根據接口文檔去開發的。前端也是同步根據接口文檔對接的。所以一般開發之前接口文檔都已經起草完畢。
對於你說的接口開發完成之後才去寫文檔的，不知道是什麼情況。
農民小羅羅
SE設計的時候就應該把接口 業務 全部定下來。後端按照設計做。除了接口設計不合理要改也應該se改文檔後前端修改，一切都應該有規有範。
小公司當我這些沒說，自己協調扯皮吧。
