亚洲欧美a,玖久AV性ab

先說說API

API大家應(yīng)該都知道吧，簡稱接口嘛。隨著現(xiàn)在移動互聯(lián)網(wǎng)的火爆，手機軟件，也就是APP幾乎快爆棚了。幾乎任何一個網(wǎng)站或者應(yīng)用都會出一款iOS或者Android APP，相比網(wǎng)頁版的體驗，APP確實各方面性能要好很多。

那么現(xiàn)在問題來了。比如QQ空間網(wǎng)站，如果我想獲取一個用戶發(fā)的說說列表。

QQ空間網(wǎng)站里面需要這個功能。

Andoid APP里面也需要這個功能。

ios APP里面也需要這個功能。

現(xiàn)在就有三套，那么按照傳統(tǒng)的開發(fā)網(wǎng)站的結(jié)構(gòu)，你就要寫3套獲取用戶說說列表的功能。也就是需要在3個地方都寫連接MySQL,查詢mysql,可想而知是非常浪費時間和經(jīng)歷的，而且安全性能很差，你可以想象你把連接mysql的配置寫在android里面，是多么危險的一件事情。人家破解出來分分鐘。

所以！當當當當！ API 就誕生了~

API就是為了解決這種情況而誕生，由一個地方統(tǒng)一提供API接口，哪個平臺想使用就直接調(diào)用這個API接口來或許信息就可以了。

比如：獲取QQ空間用戶發(fā)的說說列表：

QQ Zone web: https://api.qzone.com/user/getUserFeedList?from=web

QQ Zone Android: https://api.qzone.com/user/getUserFeedList?from=android

QQ Zone iOS: https://api.qzone.com/user/getUserFeedList?from=ios

你看。我就寫了一次代碼接口。就可以供3個地方同時使用，我僅僅是用了from參數(shù)加以區(qū)別，可能每個平臺想要的數(shù)據(jù)不一樣。

這樣不僅更加安全，快捷，最主要是分工更快速了。一個人專門寫接口，另外一個人只需要知道如何調(diào)用就可以了，完全不需要知道是如何實現(xiàn)的。

RESTFUL API

上面簡單的說了API 的由來以及使用API帶來的好處，好東西大家一用就會出問題，就像PHP一樣，用的人一多就會出現(xiàn)各種不同的規(guī)范，API也一樣，雖然都是調(diào)用API，但是，寫法卻千差萬別，維護起來很是麻煩，比如：同樣是調(diào)用QQ空間用戶說說列表，就可能有以下好幾種寫法：

https://api.qzone.com/user/getUserFeedList?from=web

https://api.qzone.com?m=user&c=getUserFeedList?from=web

https://qzone.com/api/user/getUserFeedList?from=web

https://qzone.com?m=api&c=user&a=getUserFeedList?from=web

你看，看上去千差萬別，各種狀況都有，后期維護是個大問題，再就是請求方式也不對，有些喜歡用POST ,然后所有的請求都是POST, 有些喜歡用GET ,不管多大的數(shù)據(jù)量都用GET去請求，可想而知，全都亂了套。

那么有沒有一個行業(yè)標準來規(guī)范和約束這些具體的東西呢？或者說是實施的比較好的？當然有。RESTFUL API的結(jié)構(gòu)設(shè)計就誕生了。

REST 意思是：表述性狀態(tài)傳遞（英文：Representational State Transfer）

簡單來說，RESTful API 是基于HTTP協(xié)議產(chǎn)生的一種相對簡單的API設(shè)計方案，屬于無狀態(tài)傳輸。RESTful 的核心是 everything is a “resource”，所有的HTTP action，都應(yīng)該是相應(yīng)resource上可以被操作和處理的，而API 就是對資源的管理操作，而這個具體操作是由 HTTP action 指定的。

RESTful API 是目前比較成熟的一套網(wǎng)絡(luò)應(yīng)用程序的API設(shè)計理論，RESTful API 的出現(xiàn)使前后端設(shè)備之間進行交互時可以按照這個設(shè)計更規(guī)范、更容易交流。

在一個RESTful系統(tǒng)里，客戶端向服務(wù)端發(fā)起索取資源的操作只能通過HTTP協(xié)議語義來進行交互。最常用的HTTP協(xié)議語義有以下5個：

GET : 從服務(wù)器取出資源（一項或多項）
POST：在服務(wù)器新建一個資源
PUT：在服務(wù)器更新資源（客戶端提供完整資源數(shù)據(jù)）
DELETE：從服務(wù)器刪除資源
HEAD : 從服務(wù)器獲取報頭信息（不是資源）

一些API設(shè)計者在使用這5個HTTP協(xié)議請求方法時存在語義混用的情況，某些該用PUT請求的資源，卻使用了GET。下面就簡單介紹一下每個HTTP動詞使用場景和對服務(wù)器產(chǎn)生的影響。

0.jpeg

1.jpeg

2.jpeg

3.jpeg

【注：通常說到冪等性時，還會說安全性（只讀）。GET、HEAD和OPTIONS均被認為是安全的方法，而PUT、POST、DELETE等請求都是不安全的（會修改數(shù)據(jù)）。】

WEB服務(wù)接收與返回的互聯(lián)網(wǎng)資源類型

客戶端與服務(wù)端進行交互響應(yīng)時，需要規(guī)定雙方能夠接受何種類型的媒體表現(xiàn)形式，最常見的以application開頭的媒體格式類型有：

application/json： JSON數(shù)據(jù)格式
application/xhtml+xml：XHTML格式
application/xml： XML數(shù)據(jù)格式
application/atom+xml：Atom XML聚合格式

部分小白看到這兒可能就會迷糊：RESTful Api 設(shè)計與上面提到的資源類型有何關(guān)系？

我們以地下黨和接頭人對接的場景為例，解釋下，什么是資源類型？它和API設(shè)計有何關(guān)系：

地下黨A和接口人B見面，雙方約定，以敲三下門作為接頭暗號，暗號對了就放行。

(這里敲門、敲三下的約定就類似于RESTful Api設(shè)計里面的“HTTP協(xié)議”，只有按照這個協(xié)議約定，合作才能繼續(xù)進行。)

聽到三聲敲門聲，雙方確定是自己人。事先，雙方就已經(jīng)確定以何種方式與對方交流最新情報：中文？英文？粵語？這些方式必須是對方能接收并破譯的形式。

（這里的中文、英文、粵語就類似于客戶端和服務(wù)器交互時使用的資源類型，API設(shè)計中只有使用合理的資源類型，才能讓客戶端獲取到可以讀取的資源。）

怎么樣？這么一解釋，是不是通俗易懂啦！

API設(shè)計原則

1、URL

URL中應(yīng)盡量使用名詞，盡量避免使用動詞；
應(yīng)該盡量將API部署在專用域名之下；

https://api.example.com

如果確定 API 很簡單，不會有進一步擴展，可以考慮放在主域名下；

https://example.org/api/

應(yīng)該將API 的版本號放入URL，或者將版本號放在HTTP頭信息中；

https://api.example.com/v1/

2、路徑

路徑又稱"終點"（endpoint），表示API的具體網(wǎng)址。

在RESTful架構(gòu)中，每個網(wǎng)址代表一種資源，所以網(wǎng)址中不能有動詞，只能有名詞，而且所用的名詞往往與數(shù)據(jù)庫的表格名對應(yīng)。一般來說，數(shù)據(jù)庫中的表都是同種記錄的”集合"（collection），所以API中的名詞也應(yīng)該使用復(fù)數(shù)。

舉例來說，有一個API提供動物園（zoo）的信息，還包括各種動物和雇員的信息，則它的路徑應(yīng)該設(shè)計成下面這樣。