手機用戶57280362794

1. 首先新建一個項目，然後新建一個Controller類，如下：

   

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

   

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

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

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

6. 接下來我們啟動項目，如下，啟動成功

7. 最後我們打開瀏覽器，訪問我們的api接口：

碼技術秘圈

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

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

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

start.spring.io

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

com.wukong.apidemo.controller

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

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

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

5.1、在

pom.xml

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

5.3、這時候啟動項目後，訪問：

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

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

會點代碼的大叔

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

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

Controller.Class

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

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

http://xx.yy.com

http://xx.yy.com/dispatch

Controller.function

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

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

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

這裡大家可以能注意到了，上面的函數的參數名中用的是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

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

一個存在感小透明

我們知道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。

網絡圈

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

PHP簡單示例：

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

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

特別說明

1. 使用標準的HTTP方法，規範路由請求。

   
   

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

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

4. 數據格式規範化，做好數據的安全性。

我的IT與生活

api全稱為application programming interface，應用程序接口，是軟件系統中系統間交互的組件。特別是在現流行的前後端分離的架構中應用最廣，還有移動互聯網也是常用的架構。

那對於api接口如何做呢，以下我說說我的經驗。

1.首先對系統做需求分析，整理出功能需求。

2.對系統做設計，同時進行數據庫設計後再進行接口設計，因為如果都不清楚系統的架構，數據庫設計，怎能接口設計好呢？

3.編寫接口開發框架，以JAVA為例，現在一般以Restfull為開發標準，可選的框架有springmvc，dubbo，微服務框架等，可以找下相關資料如何搭建開發框架。

4.進行接口開發，對照接口設計文檔，一個個編寫，一般接口的程序分層為interface，實現層service，dao層，Vo模型，而對外開放的用springmvc來控制和編寫。

5.接口寫好後需要本地化測試，而自測有多種方式，比如junit，postman，還有線上api測試工具，或者集成swagger接口框架，我喜歡使用postman。

6.完成自測後就可發佈到服務區提供出來聯調測試了。

接口開發大致的流程就這樣，當然很多細節沒說，比接口規範，安全等，如想進一步瞭解可關注我，一起學習進步。

小小皮匠

引語：現在互聯網那麼熱，你手裡沒幾個APP都不好意思跟別人打招呼！但是，難道APP就是全能的神嗎？答案是否定的，除了優雅的APP前端展示，其實核心還是服務器端。數據的保存、查詢、消息的推送，無不是在服務器端完成的，默默地！那麼，怎樣提供一個好的服務端API接口就是一個至關重要的問題了！

也許你會說，現在APP這麼氾濫，誰還不會寫個服務端API接口程序啊？是的，也許，你是對的，但是本文想說明的和要講的故事，是一個從零到一故事，是一個思想，是一個歷程，一個可以推演的過程！

在給出答案之前，先拋幾個問題，如果你自認為這些方面都做得很優秀，那麼恭喜你，你已經是牛人了！請於文後留下你的箴言以供借鑑，多謝！如果你感覺還有待提高的，可以嘗試在這裡找找答案，不謝！（注：本人使用PHP語言進行開發，但這不重要）

1. 採用什麼樣的服務器進行提供服務(也許不太準確)？如：soap server ? yar server ? restful ? 好吧，我相信你肯定是用的restful風格的，因為這個才是王道！

2. 怎樣確定訪問來路是正常的，或者說你怎樣管理訪問權限？（附：怎樣獲取傳遞過來的參數）

3. 有加密方式嗎？https ? 是否有區分不同場合？

4. 怎樣解決編碼問題？

5. 怎樣控制接口版本迭代問題？

6. 上傳文件怎樣處理？

7. 怎樣防止注入？（如果你也沒有用框架）

8. 怎樣提升訪問速度？怎樣提高併發？

好，看完問題，讓我們繼續故事！

前編：公司是一個小公司，剛成立不久，技術人員也很少，幾乎是一個人負責一個項目，如web前端，web後端，安卓端、IOS端。很明顯，我的任務是，服務器端接口的提供！（那裡的我，經驗也是可憐的）

1、採用什麼樣的服務器進行提供服務(也許不太準確)？如：soap server ? yar server ? restful ?

提供服務方式，之所以會想到用這幾個東西提供服務，是因為，我用的就是PHP開發啊。PHP裡就有這些東西，所以，很自然的嘛，soap,yar這兩個東西在PHP與PHP程序之間的通信的確是不錯的。但是，你要移動端對接，不止安卓，不止IOS。所以，只能國際化了唄！採用restful架構，其實說白了，也就是一個地址，就可以進行操作了，放心吧，大家都是這麼幹的，準沒錯！（附：請考慮提供接口只是進行數據的操作，倒底有沒有必要去使用一個完整的MVC框架）

2、怎樣確定訪問來路是正常的，或者說你怎樣管理訪問權限？

訪問權限，為什麼會有這個問題呢？如果是自己的網站，那麼，你所訪問的地址，就是你自己提供的，根本不需要什麼訪問權限控制！但是，如果對外提供服務，那就得考慮了。來訪的人不是內部的怎麼辦？他登錄了沒有？現在有多少人在訪問這個服務？這些東西，都應該被一目瞭然的呈現出來。那麼，怎樣控制來訪人員呢？方法1、在程序裡寫死幾個密碼一類的東西，讓客戶端訪問時，帶上此變量以驗證；方法2、為每個客戶端（我說的是安卓或ios等一套源代碼）提供一個appId,appKey，訪問時攜帶，實際上，很多大公司都是這麼幹的；方法3、使用Oauth等授權方式。很明顯，方法2是最好的方式，有了個這個東西，你也可以很方便的進行訪問的有效記錄！（實踐：建立權限表，建立訪問日誌表，如有必要，建立模塊訪問權限表，錯誤描述表）

3、有加密方式嗎？

加密，一般提供接口我們都可以採用json方式（方便啊），那就是說，所有的訪問，幾乎都是採用明碼傳輸，那麼就必須有一定的假設信息被截獲的防範措施（實際上，這個假設也很容易成立）！對於一般的信息，加一個普通的普通的簽名即可，如：appId+appKey+訪問參數+timestamp+隨機字符n個 再 md5 得到簽名，服務器端首先進行該簽名驗證，確認後，再進行後續操作！當然，對於支付一類的操作，這樣的操作還是顯得不夠安全的，那就需要特殊對待，藉助於https的加密，就安全多了！

4、怎樣解決編碼問題？

編碼問題，也許許多人看來，這並不是問題。但是我想說的是，PHP寫代碼真的很方便很隨意，md5,json_encode等都語言自帶的函數，但是對於java和swift可能就沒那麼簡單了，還得自己去找別人封裝的東西，有時稍有不對就可能導致簽名不對，所有訪問都無效！(這裡主要說的是包含中文的地方)；我們當時大家採用的都是UTF8的編輯器開發，所以並沒有什麼太大問題！

5、怎樣控制接口版本迭代問題？

版本迭代，這是個問題！因為，如果整個網站都是你的，你想怎麼改都可以，反正別人訪問也就只有你網址這一個入口。但是移動APP不一樣了，每個人都是獨立的，他們各自的版本都是不一樣的。如果共用一套接口的話，小的改動還好，向後兼容就行了，但是對於一些大方向的改動，這將是致命的，要麼強行使用戶不能使用以促使其更新，要麼你繼續寫一長篇無用的不可維護的冗餘代碼！所以，做好版本控制是必須的，主要實現為：傳入一個version參數，從而調用不同的內部接口地址，當然，你可以直接接口地址指向另一目錄！這樣，就有很多個版本接口共存了！如 /pro/api/v1.0/xxx, /pro/api/v2.0/xxx

6、上傳文件怎樣處理？

上傳文件，這也是問題，因為，其他地方都是採用的文本內容傳遞至服務器，可以直接進行數據庫保存操作，但是，對於上傳文件則不一樣。如果是網站，則一般只能使用Form表單進行提交，而且必須設置屬性multipart/form-data,聲明為文件類型。那也就是說，不能以普通的json格式提交了！解決方法有2個，方式1、先將文件以表單形式提交至服務器，服務器返回地址，再將地址組合進其他選項中，一起以json提交！方式2、整個內容以webForm表單形式提交，此類頁面單獨處理權限問題，並注意是否是偽造請求，可另加頁面隱藏token驗證！

7、怎樣防止注入？（如果你也沒有用框架）

問題7、防止注入，也許作為開發人員，說這個已經太low，但是我還是忍不住提了，因為，真的很重要，其實，接口要做的事情很簡單，接受數據，保存數據，返回狀態。所以，真心覺得，沒必要去用一些很成熟的大型框架，太臃腫！那麼注入問題，就只有你自己解決了。php 使用 mysql_real_escape_string 及 htmlspecialchar進行過濾，基本也就夠了！

8、怎樣提升訪問速度？怎樣提高併發？

接口的訪問速度，這個是很重要的。你有沒有看到哪個APP訪問速度很慢，大家還願意用他的？做到秒開才是王道，由於各種驗證，各種日誌記錄，已經消耗了不少時間，所以更要注意效率問題。索引、緩存、負載均衡、分佈式，用起來。。。 哈哈，太寬泛了

從最初什麼都沒有，到最後，一整套接口的完成，大概花了一個多月時間，感覺還是有很多不OK的地方，再後來準備做消息推送，做長連接，結果由於某些原因，項目被中斷，也就不了了之了。

寫一點當時的過程，就當是一點點的收穫吧。還記得，當初開始做的時候，參考資料實在太少，以至於做很多東西，都沒有信心，只是憑感覺！！希望這篇文章能幫到部分處於這個時期的人！

其實不管是做什麼樣的開發，都應該是從核心要解決的問題出發的，當你把問題都解決了之後，也許，一個好的設計好的架構就已經悄然呈現！這也許就是解決問題之美吧！

歡迎批評，歡迎指正，歡迎提問！

情感小小的世界

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

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

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

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

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

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

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

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

陸垚知瑪麗

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

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

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

Java高級開發

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

關鍵字: 科技 數據格式 硬件