如何做一個api接口?

手機用戶57280362794


我們知道API其實就是應用程序編程接口,可以把它理解為是一種通道,用來和不同軟件系統間進行通信,本質上它是預先定義的函數。API有很多種形式,最為常見的就是以HTTP協議來提供服務(如:RESTful),只要符合規範就可正常使用。現在各類企業在信息化這塊都會用到第三方提供的API,也會提供API給第三方調用,因此設計API也是需要慎重的。

具體該如何開發設計一個良好的API接口呢?

明確功能

在設計之初就需要將API詳細功能整理出來,按業務功能點或模塊來劃分,明確此API需要提供哪些功能。

代碼邏輯清晰

保持代碼整潔性,增加必要的註釋,接口確保功能單一,如果一個接口需要複雜的業務邏輯,建議拆分成多個接口或者將功能獨立封裝成公共方法,避免接口裡代碼過多,不利於後期人員維護和後期迭代。

必要的安全校驗機制

目前Web應用很容易遭遇數據竊取、篡改、非法提交、重複請求等安全問題,API的安全校驗機制是必不可少的。常用解決方案就是採用數字簽名形式,將每個HTTP請求都加上簽名,服務器端校驗簽名合法性來保證請求是否合法。

日誌記錄

為便於及時定位問題,日誌是必不可少的。

降低耦合度

一個良好的API應該是越簡單越好,如果API間業務耦合度過高很容易因某塊代碼異常導致相關API的不可用,儘可能避免API間的複雜調用關係。

返回有意義的狀態碼

API返回數據中要攜帶狀態碼數據,比如200代表請求正常,500代表服務器內部錯誤等。返回通用的狀態碼有利於問題定位,比如可參考以下狀態碼:

開發文檔

既然API是提供給第三方或內部使用的,那開發文檔是必不可少的,否則他人不知道如何調用。一個良好的API開發文檔應包含以下元素:

1、當前API架構模式講解、開發工具及版本、系統依懶等環境信息;

2、當前API提供哪些功能;

3、API模塊間的依懶關係;

4、調用規則、注意事項;

5、部署注意事項等。


一個好的API必然是易使用,易看懂,易擴展,難誤用,安全性高,功能強大的API。要做到上面幾點並不容易,但是我們應當遵從上述原則結合業務本身合理的劃分設計API。


以上就是我的觀點,對於這個問題大家是怎麼看待的呢?歡迎在下方評論區交流 ~ 我是科技領域創作者,十年互聯網從業經驗,歡迎關注我瞭解更多科技知識!

網絡圈


因為我是做Java開發的,所以就按照Java的開發流程說一下;首先一個好的API接口,設計是要下功夫的,細節就不在這裡說了,這裡還是主要說實現;如果開發環境具備,前後大概也就不到十分鐘,就可以完成一個簡單的API接口的開發(只是個demo)。


0、開發前準備:電腦上需要安裝JDK、Maven和IDE。

1、新建一個基於Spring Boot的項目,為了快速完成,我選擇登錄到【

start.spring.io

】網站上,生成一個項目。通過【Search dependencies to add】可以選擇需要引入的包,我這裡只引入了Web,也就是Spring MVC;假如你需要通過Mybatis訪問數據庫,也可以在這裡選擇;然後點擊生成項目。

2、將下載好的項目,解壓後引入到你的IDE中,新建一個類:

com.wukong.apidemo.controller

.ApiController

3、在這個類中增加一個方法,並主要使用@RestController、@RequestMapping、@ResponseBody兩個標籤,整個類大概是這個樣子:

4、這時候最簡單的一個API接口就完成了,我們可以啟動項目後,訪問對應的接口地址,得到接口的返回信息:

5、我們再對這個接口稍微加工一些,讓swagger幫助我們生成一個接口文檔:

5.1、在

pom.xml

中進入swagger需要的包:

5.2、對ApiController增加:@Api、@ApiOperation、@ApiImplicitParams等標籤:

5.3、這時候啟動項目後,訪問:

http://10.141.48.41:8080/swagger-ui.html

5.4、這裡留了一個小問題,swagger的配置少了一步,按照上面的做飯,訪問swagger的頁面是會報404的,大家可以嘗試解決。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解,希望能得到你的關注。


會點代碼的大叔


首先新建一個項目,然後新建一個Controller類,如下:

然後類上面加上註解@RequestMapping,這個註解要帶上一個路徑,這個路徑會成為接口的一部分,然後再加上@RestController,這個註解是說明接口返回的數據格式為json,因為現在一般都是json數據格式交互

接下來在類裡面新建一個方法,如下:

這時候我們還需要在方法上面再加上一個註解@RequestMapping,或者@GetMapping等其他註解

現在基本一個接口就定義完了,我們在方法中加一點信息返回給調用方,如下:

接下來我們啟動項目,如下,啟動成功

最後我們打開瀏覽器,訪問我們的api接口:


碼技術秘圈


API(Application Programming Interface,應用程序編程接口),目的是提供應用程序與開發人員基於某軟件或硬件訪問獲取數據。


api接口的返回數據格式目前來說用的最多的是json數據格式。各個語言實現的方式有所不同,但是api使用者無須關心實現細節。下面是用php實現一個json數據格式的代碼,希望對你有所幫助。


PHP簡單示例:

假設接口訪問地址 http://127.0.0.1/api.php,api.php文件內容是


訪問接口 http://127.0.0.1/api.php


特別說明

上術示例只是最最基本的實現方式上的一個小示例!市面上再複雜規範的API,無非就是一個根據客戶端的請求參數對數據的篩選。所以這裡也給出一個比較規範的API設計思路

使用標準的HTTP方法,規範路由請求。

無狀態性,每個請求都是一個新的請求來對待。

支持多種資源表示方式 (xml, json等)。

數據格式規範化,做好數據的安全性。


我的IT與生活


作為BAT的Java開發工程師,來分享下我在公司裡寫的項目(脫敏)中的封裝api接口部分。

我們使用的是SSM框架,但是這裡其實不論是SSM還是SSH,抑或是SPRING BOOT,接下來的介紹都是通用的,因為主要是通過介紹註解(annotation),而不是xml文件。

Controller.Class

首先,API接口需要出現在controller層,因此,在類名上方,需要至少兩個註解,@controller,用於在項目啟動的時候告訴spring,這個類是controller層的,需要加載好;@requestMapping,這個註解相當於指明瞭api的url中的一部分。

如果一個服務綁定的域名是

http://xx.yy.com

,然後requestMapping中的內容意味著,url為

http://xx.yy.com/dispatch

/.... 格式的請求,會被轉發到當前這個類中。

Controller.function

看完接下來我們看函數部分,這裡首先也要加一個responseBody註解,這個註解的含義是將controller層中,函數的返回對象通過轉換器,轉換為指定的格式,寫入到http response返回對象的body中去,也就是說下面這個函數返回的String,直接作為response的body內容返回給了用戶。

接下來,依舊是requestMapping註解,相信大家也能瞭解了,複用上面的例子,當url為

http://xx.yy.zz/dispatch/validate

的時候,相當於調用了這個validateParams函數,並且這個請求request的body就會作為body參數,一併傳入這個函數。

這裡大家可以能注意到了,上面的函數的參數名中用的是requestBody,而下面用的是formParam,雖然二者都是post請求,但是參數接收方式卻不一樣。這就意味著,代碼裡指定了不同的接收方式,request的body裡也必須用對應的方式才能將數據傳遞給函數。上圖中body用raw形勢的就可以,而下圖則要求用application/x-www-form-urlencoded格式的body。

最後,上面介紹的都是post請求的api,下圖介紹了GET請求的api如何寫。可以看出,註解方面,requestMapping裡指定requestMethod為GET即可。在函數的參數方面,需要用requestParma註解來接收,如下圖。當你發送

http://xx.yy.com

/dispatch/getMyContract?username=xiaomin&password=123 這個請求的時候,就相當於調用了下面的getMyContract函數,並且傳入的username參數為xiaomin,password參數為123.

我是蘇蘇思量,來自BAT的Java開發工程師,每日分享科技類見聞,歡迎關注我,與我共同進步。


一個存在感小透明


API接口設計個人覺得需考慮其擴展性能特別是對外公共接口,否則多個業務需求類似會存在兩套API的情況,比較浪費資源。其次api名稱,請求參數,返回結果必須有確定含義,容易上手,返回結果一般我設計時分為2部分,系統層面信息,業務層面信息,系統層面例如api調用異常,一般用約定好的錯誤碼標識,業務層面就很寬泛,例如銀行業務聯網核查,查不到用戶信息,從系統層面這是OK的,業務層面肯定是不行的,不可能用戶在銀行有賬戶卻沒有用戶信息,當然可能數據庫在做遷移導致暫時訪問為空,這種業務錯誤也可以通過狀態碼或者狀態標識boolean值+錯誤信息返回給客戶端,這樣api出問題可以快速定位是系統問題還是業務問題


定格往憶


作為一名開發者,在此發表我的一些觀點,一個好的Api一定是一個可讀性比較高的Api項目。可以從以下幾點入手

1、不論Api用何種語言編寫,多少人編寫,都需要達到每個接口的輸出規則都是一致的。確定好開發前的開發規範,包括入參使用何種駝峰命名,返回的json數據又是以何種規則對外輸出這些都需要在編碼前考慮好。

2、Api需要對入參做必要驗證。

3、需要提供統一的驗證機制,在一定程度上防止遭遇惡意請求。

4、增加必要的日誌記錄,為以後的排查提供數據依據。

5、考慮Api的響應速度可以適當的引用緩存技術,比如Redis。

6、做好項目的文檔記錄。

以上就是我的一些建議,我是一名開發人員,喜歡我的歡迎關注🍀🍀🍀🍀🍀🍀🍀


陸垚知瑪麗


現在的Web開發基本都是多端共用同一Api,也就是當前最流行主導的前後端完全分離的模式去開發Api接口。

而我們通常用的最正規標準的又是Restful Api。就是在定義接口的時候不像以前那樣隨心所欲的想怎麼定義就怎麼定義,基本都是按照固定模式,達到見名知意基本不需要看接口註釋就知道怎麼調用。

就比如,現在大家都默認約定俗成的獲取統一用Get請求,新增用Post請求,修改用Patch請求,刪除用Delete請求,這樣對於接口使用者從接口的請求方式就立馬知道什麼情況調用哪個指定接口,很方便高效。


Java高級開發


1. 使用原生php編寫一個統一網關入口文件gateway.php

2. gateway.php入口文件主要負責入參如appid,timestamp,action,format,sign,encrypted_data等校驗和解析,並調度到具體邏輯代碼去處理結果,然後輸出標準格式的json或xml字符串

3. 建議gateway.php統一用post來接收請求參數,敏感信息如身份證號、銀行卡號等用AES加密,每條請求都加上時間戳參數以及md5簽名

4. API文檔直接用Markdown語法書寫即可


web架構師自我修煉


API(Application Programming Interface,應用程序編程接口),目的是提供應用程序與開發人員基於某軟件或硬件訪問獲取數據。

api接口的返回數據格式目前來說用的最多的是json數據格式。各個語言實現的方式有所不同,但是api使用者無須關心實現細節。下面是用php實現一個json數據格式的代碼,希望對你有所幫助。

PHP簡單示例:

假設接口訪問地址 http://127.0.0.1/api.php,api.php文件內容是

訪問接口 http://127.0.0.1/api.php