接口請求的流程？接口請求的過程應(yīng)該是1請求接口數(shù)據(jù)參數(shù)2請求上游接口3獲取接口返回值4根據(jù)接口返回值判斷請求是否成功，并接收數(shù)據(jù)進(jìn)行業(yè)務(wù)邏輯操作一個很好的問題。我是一個web應(yīng)用程序架構(gòu)師，多年來一直

接口請求的流程？

接口請求的過程應(yīng)該是

1請求接口數(shù)據(jù)參數(shù)

2請求上游接口

3獲取接口返回值

4根據(jù)接口返回值判斷請求是否成功，并接收數(shù)據(jù)進(jìn)行業(yè)務(wù)邏輯操作

一個很好的問題。我是一個web應(yīng)用程序架構(gòu)師，多年來一直致力于回答這個問題。歡迎跟我來了解更多。

后端提供接口文檔為時已晚，這是合理和不合理的。根據(jù)具體情況，總有解決辦法。讓我談?wù)勎业挠^點(diǎn)。

不合理：成熟的技術(shù)團(tuán)隊(duì)重視功能設(shè)計，在編寫代碼之前有完整的技術(shù)文檔和功能定義。即使在TDD測試驅(qū)動的開發(fā)模式下，測試數(shù)據(jù)已經(jīng)準(zhǔn)備好了，那么接口邏輯就已經(jīng)確定了接口文檔是否編寫好了，理清它們是很自然的。

-第一，主觀原因。原因是多方面的，比如趕進(jìn)度，沒有時間，不懶得寫，甚至在開發(fā)前沒有仔細(xì)設(shè)計，在做的時候也有變化。真的沒有好辦法。

-客觀原因：需求在變化，功能在變化，接口也在變化。所以，如果你寫了一個文件，它的自然更新和維護(hù)？天哪？

有解決方案嗎？建議嘗試：[1]swagger接口文檔，將文檔集成到代碼中，集成維護(hù)文檔和修改代碼，在修改代碼邏輯的同時方便修改文檔描述。

2、郵遞員界面測試工具，導(dǎo)入導(dǎo)出JSON文件，高效的團(tuán)隊(duì)合作。Postman支持各種請求方法和配置環(huán)境變量，對返回的結(jié)果進(jìn)行測試和驗(yàn)證，支持批量自動操作，可與自動構(gòu)建系統(tǒng)集成。

后端開發(fā)完接口才給出接口文檔，合理嗎？你怎么看？

我們在軟件開發(fā)或合作中經(jīng)常會遇到“API”這個詞，比如API接口、API調(diào)用、API接口函數(shù)等，那么什么是API呢？

API，通俗地說，相當(dāng)于我們經(jīng)?？吹目苹秒娪爸锌臻g站或航天器與其他空間設(shè)備連接的開口。當(dāng)別人的航天飛機(jī)要與你對接時，你必須告訴你的空間站的外部接口標(biāo)準(zhǔn)規(guī)范，如接口名稱、接口尺寸、接口程序等，以確保兩者能通過這個接口成功建立聯(lián)系，完成彼此內(nèi)容的交換。

API的標(biāo)準(zhǔn)術(shù)語是應(yīng)用程序編程接口。

API是一些預(yù)定義函數(shù)，用于為應(yīng)用程序和開發(fā)人員提供訪問基于特定軟件或硬件的一組例程的能力，而無需訪問源代碼或了解內(nèi)部工作機(jī)制的詳細(xì)信息。這也很容易理解。一個標(biāo)準(zhǔn)的軟件，如今天的頭條應(yīng)用程序，可以向其他人打開API接口。例如，字節(jié)跳動的公司需要隨時了解今日頭條應(yīng)用的用戶狀態(tài)，所以他們可以讓今日頭條開發(fā)一個名為“用戶狀態(tài)/用戶”的程序，然后母公司通過自己的統(tǒng)計軟件，通過這種方式獲得“用戶”，即頭條用戶總數(shù)、新用戶數(shù)，用戶的活躍狀態(tài)和熱點(diǎn)數(shù)據(jù)將以字節(jié)跳動的方式顯示在統(tǒng)計軟件的屏幕上。統(tǒng)計軟件不需要知道哪個用戶發(fā)布了什么內(nèi)容。如果需要，它還需要制作一個API接口來調(diào)用它。

因此，API是操作系統(tǒng)對應(yīng)用程序的調(diào)用接口。應(yīng)用程序通過調(diào)用操作系統(tǒng)的API使操作系統(tǒng)執(zhí)行應(yīng)用程序的命令（動作）。在windows中，系統(tǒng)API是通過函數(shù)調(diào)用提供的。