問答專欄Q & A COLUMN
我們知道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。
以上就是我的觀點，對于這個問題大家是怎么看待的呢？歡迎在下方評論區交流 ~ 我是科技領域創作者，十年互聯網從業經驗，歡迎關注我了解更多科技知識！
評論0
加載中...
因為我是做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的，大家可以嘗試解決。
評論0
加載中...
首先新建一個項目，然后新建一個Controller類，如下：
然后類上面加上注解@RequestMapping，這個注解要帶上一個路徑，這個路徑會成為接口的一部分，然后再加上@RestController，這個注解是說明接口返回的數據格式為json，因為現在一般都是json數據格式交互
接下來在類里面新建一個方法，如下：
這時候我們還需要在方法上面再加上一個注解@RequestMapping，或者@GetMapping等其他注解
現在基本一個接口就定義完了，我們在方法中加一點信息返回給調用方，如下：
接下來我們啟動項目，如下，啟動成功
最后我們打開瀏覽器，訪問我們的api接口：
評論0
加載中...
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等)。
數據格式規范化，做好數據的安全性。
評論0
加載中...
作為BAT的Java開發工程師，來分享下我在公司里寫的項目（脫敏）中的封裝api接口部分。
我們使用的是SSM框架，但是這里其實不論是SSM還是SSH，抑或是SPRING BOOT，接下來的介紹都是通用的，因為主要是通過介紹注解（annotation），而不是xml文件。
首先，API接口需要出現在controller層，因此，在類名上方，需要至少兩個注解，@controller，用于在項目啟動的時候告訴spring，這個類是controller層的，需要加載好；@requestMapping，這個注解相當于指明了api的url中的一部分。
如果一個服務綁定的域名是
http://xx.yy.com
，然后requestMapping中的內容意味著，url為http://xx.yy.com/dispatch
/.... 格式的請求，會被轉發到當前這個類中。看完接下來我們看函數部分，這里首先也要加一個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開發工程師，每日分享科技類見聞，歡迎關注我，與我共同進步。
評論0
加載中...
以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
要求
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為例：
格式不太好調整， 代碼參見本人的博客： https://china-testing.github.io/flask_api.html
評論0
加載中...
如果只是一個簡單API實例的話，不涉及數據庫等，可以實現的語言可以說非常的多，但是我覺得比較簡單的是nodejs和go 因為他們有自己的原生服務模塊，nodejs有http模塊，go有net模塊，都直接可以起一個web服務，無需Apache，Tomcat等web服務器
評論0
加載中...
現在的Web開發基本都是多端共用同一Api,也就是當前最流行主導的前后端完全分離的模式去開發Api接口。
而我們通常用的最正規標準的又是Restful Api。就是在定義接口的時候不像以前那樣隨心所欲的想怎么定義就怎么定義，基本都是按照固定模式，達到見名知意基本不需要看接口注釋就知道怎么調用。
就比如，現在大家都默認約定俗成的獲取統一用Get請求，新增用Post請求，修改用Patch請求，刪除用Delete請求，這樣對于接口使用者從接口的請求方式就立馬知道什么情況調用哪個指定接口，很方便高效。
評論0
加載中...
API接口設計個人覺得需考慮其擴展性能特別是對外公共接口，否則多個業務需求類似會存在兩套API的情況，比較浪費資源。其次api名稱，請求參數，返回結果必須有確定含義，容易上手，返回結果一般我設計時分為2部分，系統層面信息，業務層面信息，系統層面例如api調用異常，一般用約定好的錯誤碼標識，業務層面就很寬泛，例如銀行業務聯網核查，查不到用戶信息，從系統層面這是OK的，業務層面肯定是不行的，不可能用戶在銀行有賬戶卻沒有用戶信息，當然可能數據庫在做遷移導致暫時訪問為空，這種業務錯誤也可以通過狀態碼或者狀態標識boolean值+錯誤信息返回給客戶端，這樣api出問題可以快速定位是系統問題還是業務問題
評論0
加載中...
說明：
1）以下以
.NET為開發平臺創建api接口，并且引入Swagger配置接口文檔
2）
代碼部分有點混亂，可轉到文章底部有文章鏈接查看一、創建Net Web API項目
1.新建web應用程序
2.選擇空模板，并且勾選web api
3.生成web api項目后，添加controller文件
4.自動回生成content、views等文件夾及文件
5.可直接運行，程序異常
6.Global.asax 添加配置
代碼如下：
7.修改路由配置，制定默認controller、action
代碼如下：
8.生成默認view
9.重新編譯，運行程序。成功顯示home的index頁面
二、引入Swagger
1.打開NuGet程序包
2.“瀏覽”頁簽下，搜索swagger, 找到swashbuckle,右側選擇webapi項目，進行安裝。
3.找到swagger.net.ui,右側選擇webapi項目，進行安裝。
4.安裝完成后，生成相關配置文件，可直接關閉掉nuget,
三、配置Swagger
1.修改默認頁（前面步驟中生成的HomeController的index頁面僅僅是測試用，到此步驟也可以刪除掉）
代碼如下：
2.運行程序，出現報錯，因為還缺少配置
3.打開應用程序屬性
選擇“生成”，勾選xml文檔，這個xml里面會自動配置swagger
4.打開SwaggerNet.cs,屏蔽如下兩行代碼。
5.重新運行，看到下面頁面則代表swagger配置成功。
四、編寫接口及調試
1.新建測試model
代碼如下：
2.新建一個測試controller
代碼如下：
3.重新運行，看到新建的接口。
4.點擊“TestAPI”,再點擊“api/TestAPI”可打開接口詳細內容。
5.接口測試。得到后臺返回響應，則接口陳宮
五、注意說明
接口地址為http://localhost:64530/api/TestAPI
可利用Postman做測試
評論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
