如何做一個api介面?

Noah_WB發表於2023-03-06

如何做一個api介面?:我們知道API其實就是應用程式程式設計介面,可以把它理解為是一種通道,用來和不同軟體系統間進行通訊,本質上它是預先定義的函式:-api,介面

1

我們知道API其實就是應用程式程式設計介面,可以把它理解為是一種通道,用來和不同軟體系統間進行通訊,本質上它是預先定義的函式。API有很多種形式, 整潔性,增加避免介面裡程式碼過多,不利於後期人員維護和後期迭代。

必要的安全校驗機制

目前Web應用很容易遭遇數字簽名形式,將每個HTTP請求都加上簽名,伺服器端校驗簽名合法性來保證請求是否合法。

日誌記錄

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

降低耦合度

一個良好的API應該是越簡單越好,如果API間業務耦合度過高很容易因某塊程式碼異常導致相關API的不可用, API返回資料中要攜帶狀態碼資料,比如200代表請求正常,500代表伺服器內部錯誤等。返回通用的狀態碼有利於問題定位,比如可參考以下狀態碼:

開發文件

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

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

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

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

4、呼叫規則、注意事項;

5、部署注意事項等。



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


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

2

因為我是做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、這時候啟動專案後,訪問:

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

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

3

  1. 首先新建一個專案,然後新建一個Controller類,如下:

  2. 然後類上面加上註解@RequestMapping,這個註解要帶上一個路徑,這個路徑會成為介面的一部分,然後再加上@RestController,這個註解是說明介面返回的資料格式為json,因為現在一般都是json資料格式互動

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

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

  5. 現在基本一個介面就定義完了,我們在方法中加一點資訊返回給呼叫方,如下:

  6. 接下來我們啟動專案,如下,啟動成功

  7. 最後我們開啟瀏覽器,訪問我們的api介面:

4

API(Application Programming Interface,應用程式程式設計介面),目的是提供應用程式與開發人員基於某軟體或硬體訪問獲取資料。


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


訪問介面


特別說明

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

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

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

  4. 資料格式規範化,做好資料的安全性。

5

作為BAT的Java開發工程師,來分享下我在公司裡寫的專案(脫敏)中的封裝api介面部分。

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

Controller.Class

首先,API介面需要出現在controller層,因此, 連結:

快速編碼:將開發特性的速度提高大約200%到300%。

  • 直觀:強大的編輯器支援。到處都是。更少的除錯時間。

  • 簡而言之:最小化程式碼重複。每個引數宣告有多個特性。

  • 基於標準:基於(並且完全相容)api的開放標準。

感興趣的可以嘗試一下。


如果覺得有幫助的話,麻煩幫忙點個贊再走吧~

7

以python3 + PostgreSQL 為例:


術語

REST: REpresentational State Transfer

目標

  • GET - /api/Category - Retrieve all categories

  • POST - /api/Category - Add a new category

  • PUT - /api/Category - Update a category

  • DELETE - /api/Category - Delete a category

  • GET - /api/Comment - Retrieve all the stored comments

  • POST - /api/Comment - Add new comment

要求

  • python3.*
  • PostgreSQL

requirements.txt的內容如下:

  • flask - Python的微框架

  • flask_restful - 這是Flask的擴充套件,可快速構建REST API。

  • flask_script - 提供了在Flask中編寫外部指令碼的支援。

  • flask_migrate - 使用Alembic的Flask應用進行SQLAlchemy資料庫遷移。

  • marshmallow - ORM/ODM/框架無關的庫,用於複雜資料型別(如物件)和Python資料型別轉換。

  • flask_sqlalchemy - Flask擴充套件,增加了對SQLAlchemy的支援。

  • flask_marshmallow - 這是Flask和marshmallow的中間層。

  • marshmallow-sqlalchemy - 這是sqlalchemy和marshmallow的中間層。

  • psycopg - Python的PostgreSQL API。

安裝依賴



安裝配置PostgreSQL

這裡以 Ubuntu 16.04為例:


格式不太好調整, 程式碼參見本人的部落格:


imageimage

8

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

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

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

9

如果只是一個簡單API例項的話,不涉及資料庫等,可以實現的語言可以說非常的多,但是我覺得比較簡單的是nodejs和go 因為他們有自己的原生服務模組,nodejs有http模組,go有net模組,都直接可以起一個web服務,無需Apache,Tomcat等web伺服器

10

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


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70026910/viewspace-2938318/,如需轉載,請註明出處,否則將追究法律責任。

相關文章