接口編程中，為什么只用get和post？得到，帖子就夠了。。restful接口做什么？完成這項(xiàng)工作很好。別修那些花哨的這是一個(gè)非常有趣的問題。作為一個(gè)工作多年的程序員，讓我來回答這個(gè)問題。首先，接口是

接口編程中，為什么只用get和post？

得到，帖子就夠了。。restful接口做什么？完成這項(xiàng)工作很好。別修那些花哨的

這是一個(gè)非常有趣的問題。作為一個(gè)工作多年的程序員，讓我來回答這個(gè)問題。

首先，接口是編程過程中最常見的元素，無論是研發(fā)級(jí)程序員還是應(yīng)用級(jí)程序員，在日常編程過程中都離不開接口。接口可以看作是在編程過程中連接各種資源的一種方式。在基于角色的開發(fā)時(shí)代，程序員不可能獨(dú)自完成從硬件到軟件的所有開發(fā)過程。因此，沒有界面的幫助，整個(gè)軟件開發(fā)就無法實(shí)現(xiàn)大規(guī)模的開發(fā)。

隨著云計(jì)算技術(shù)的逐步普及，接口對于程序設(shè)計(jì)的意義得到了進(jìn)一步體現(xiàn)，現(xiàn)在接口已經(jīng)進(jìn)入“微接口”時(shí)代，以滿足大數(shù)據(jù)時(shí)代對程序設(shè)計(jì)的要求。所謂“微接口”與“微服務(wù)”的概念相對應(yīng)，使程序調(diào)用更輕，更容易實(shí)現(xiàn)模塊化封裝。當(dāng)然，微接口的編程對云計(jì)算平臺(tái)尤其是PAAS提出了更高的要求。

如果現(xiàn)在的程序員不能通過接口完成資源的整合，那么編程系統(tǒng)將會(huì)有很大的變化。從目前的技術(shù)架構(gòu)來看，完全沒有接口編程是不現(xiàn)實(shí)的。也許在未來的人工智能時(shí)代，程序員只能關(guān)心業(yè)務(wù)邏輯，而不需要關(guān)心各種資源的集成。到那時(shí)，接口可能會(huì)以另一種形式出現(xiàn)。

如果程序員編程沒有接口，他們將面臨三大障礙：一是如何完成硬件資源的管理；二是如何完成各種開發(fā)資源的調(diào)用；三是如何完成功能的擴(kuò)展。當(dāng)然，沒有界面的支持，程序員需要從頭開始做所有的工作。在目前的技術(shù)架構(gòu)下，這種開發(fā)方式是難以想象的，也不是“996”能解決的問題。

如果今天沒有API接口，今天的程序員如何編程？

簡單明了。

。

此狀態(tài)代碼用于標(biāo)識(shí)當(dāng)前請求的狀態(tài)，以便快速查找問題。您可以參考HTTP狀態(tài)碼來劃分?jǐn)?shù)字段來表示具體的操作狀態(tài)，如：

1000~1999:參數(shù)級(jí)錯(cuò)誤

2000~2999:邏輯錯(cuò)誤

3000~3999:代碼異常和錯(cuò)誤

此字段主要用來描述錯(cuò)誤。在正常響應(yīng)中，此字段為空，一旦出現(xiàn)錯(cuò)誤，將提示具體的錯(cuò)誤原因。

此數(shù)據(jù)結(jié)構(gòu)是調(diào)用者需要調(diào)用的數(shù)據(jù)。不同的企業(yè)有不同的領(lǐng)域。

分布式之API接口返回格式如何優(yōu)雅設(shè)計(jì)？

一個(gè)非常好的問題。您可以嘗試以下方法：

當(dāng)nginx配置路由和轉(zhuǎn)發(fā)時(shí)，重新拼接路徑和參數(shù)。

1）路徑包含參數(shù)，如URL/{name}，在java開發(fā)過程中@pathvariable可以讀取這些參數(shù)

2）請求體參數(shù)包含路由信息，可以解析這些信息來實(shí)現(xiàn)判斷邏輯