① RESTful 介面教程
我們現實生活中的協議是指相互遵守的規定，單方面違背，協議不成立。
而在互聯網交互的過程中，也存在這許多協議，例如 FTP、HTTP、STMP、TCP/IP 等。
而 HTTP 協議則是 web 伺服器 和 web 客戶端 達成的一種可靠的數據傳輸協議，通過 HTTP 可以從遍布全世界的 Web 伺服器上將 JPEG 圖片，HTML 頁面，文本文件，MPEG 電影，WAV 音頻文件和其他資源信息塊迅速、便捷、可靠地搬移到人們桌面上的 Web 瀏覽器上去。它能夠確保數據在傳輸的過程當中不會損壞或者產生混亂。這樣，對用戶來說是個好事，同樣對 Internet 應用的開發人員來說也是一件好事。因為我們在開發過程中也不需要擔心自己的頁面和數據會在傳輸過程中發生破壞和畸變了。
Web 內容都是 存儲在 Web 伺服器 上的。Web 伺服器所使用的是 HTTP 協議，因此經常會被稱為 HTTP 伺服器。這些 HTTP 伺服器存儲了網際網路中的數據，如果 HTTP 客戶端發出請求的話，它們會提供數據。客戶端向伺服器發送 HTTP 請求，伺服器會在 HTTP 響應中回送所請求的數據。
那麼一次請求和響應的過程中發生了什麼？
web 伺服器是 web 資源的宿主 ，而 web 資源就是我們常見的 web 內容的源頭，最簡單的 web 資源就是我們伺服器中的靜態文件：文本文件，HTML 文檔，JPEG 圖片文件，AVI 文件等等。
當然 web 資源也可以是動態生成的，類似搜索引擎生成的頁面，QQ 空間的動態等，總之，所有類型的內容來源都是資源。
網際網路上有數千種不同類型的數據類型，HTTP 在傳輸的過程中為每個傳輸的數據都打上了名為 MIME 類型的數據類型標簽，描述並標記多媒體內容。
web 瀏覽器請求一個網站的時候往往會發布 多個 HTTP 請求 ，比如我們在瀏覽一個具有豐富圖片的的 web 頁面的時候，瀏覽器會執行一次 HTTP 請求來獲取描述頁面布局的 HTML，然後發布另外的請求來獲取每個嵌入式的圖片，這些圖片甚至可能位於不同的伺服器上。因此，一個 web 頁面通常不是單個資源，而是一組資源的集合。
web 伺服器會為所有的 HTTP 對象數據附加一個 MIME 類型 ，當瀏覽器從伺服器中取回一個對象的時候，會查看相關的 MIME 類型。看看它是否知道應該如何處理這個對象。對象的類型寫在響應的 content-type 頭 中；同樣，請求的時候瀏覽器也會告知伺服器請求數據類型。
常見的 MIME 類型：
以 application 開頭的媒體格式類型：
MIME 參考手冊： W3school MINE類型
大部分 URL 都遵循一種標准格式， 這種格式包含三個部分。
URI = Uniform Resource Identifier 統一資源 標志符
URL = Uniform Resource Locator 統一資源 定位符
URN = Uniform Resource Name 統一資源 名稱
翻譯成人話: URI 是抽象的定義，不管用什麼方法表示，只要能定位一個資源，就叫 URI，本來設想的的使用兩種方法定位。
1）URL 用地址定位
2）URN 用名稱定位
舉個例子：去村子找個具體的人（URI）。如果用地址：某村多少號房子第幾間房的主人就是 URL， 如果用身份證號 + 名字，去找就是 URN 了。
目前 WEB 上就 URL 流行開了，平常見得 URI 基本都是 URL。
1）HTTP 和 HTTPS 的相同點
2）HTTP 和 HTTPS 的不同之處
3）如何選擇 HTTP 和 HTTPS 協議
HTTP 支持幾種不同請求和命令，這些命令被稱為 HTTP 方法，每條 HTTP 請求報文都包含一個方法。 這個方法會告訴伺服器要執行什麼動作（獲取一個 Web 頁面、發送一段信息、刪除一個文件等）。
請求方法如下：
狀態碼分成如下幾個系列：
常見的 HTTP 狀態碼：
從 Web 客戶端發往 Web 伺服器的 HTTP 報文稱為請求報文（request message）。從伺服器發往客戶端的報文稱為響應報文（response message）。
HTTP 報文包括以下三個部分:
以上內容復制自： http://www.cnblogs.com/Joans/p/3956490.html
使用火狐和 chrome 瀏覽器打開一個網頁，找到其中一個網路請求查看報文。
1）協議
2）域名
3）介面版本控制規范
格式規范如下：
更新版本後可以使用 v2、v3 等依次遞加。
4）介面路徑規范
格式規范如下：
5）介面命名規范
格式規范如下：
6） HTTP 請求方法
格式規范如下：
GET https://api.xxxxx.com/v1/zoos ：列出所有動物園
POST https://api.xxxxx.com/v1/zoos ：新建一個動物園
GET https://api.xxxxx.com/v1/zoos/ID ：獲取某個指定動物園的信息
PUT https://api.xxxxx.com/v1/zoos/ID ：更新某個指定動物園的信息（提供該動物園的全部信息）
PATCH https://api.xxxxx.com/v1/zoos/ID ：更新某個指定動物園的信息（提供該動物園的部分信息）
DELETE https://api.xxxxx.com/v1/zoos/ID ：刪除某個動物園
GET https://api.xxxxx.com/v1/zoos/ID/animals ：列出某個指定動物園的所有動物
DELETE https://api.xxxxx.com/v1/zoos/ID/animals/ID ：刪除某個指定動物園的指定動物
注意：修改有兩個方法 PUT 和 PATCH。
假設 URL 位置有一組數據 UserInfo，包括 UserID、UserName 等 20 個欄位
需求：用戶修改了 UserName，其他不變
• 採用 PATCH，僅向 URL 提交 UserName 的局部更新請求
• 採用 PUT，必須將所有 20 個欄位一並提交到 URL，未提交欄位被刪除
PATCH 的最主要好處：節省網路帶寬
7）介面信息過濾
格式規范如下：
?limit=10：指定返回記錄的數量
?offset=10：指定返回記錄的開始位置。
?page=2&per_page=100：指定第幾頁，以及每頁的記錄數。
?sortby=name&order=asc：指定返回結果按照哪個屬性排序，以及排序順序。
?animal_type_id=1：指定篩選條件
參數的設計允許存在冗餘，即允許 API 路徑和 URL 參數偶爾有重復。比如， GET /zoo/ID/animals 與 GET /animals?zoo_id=ID 的含義是相同的。
8）請求參數規范
9）介面返回數據
格式規范如下：
status:：介面的執行狀態
data：介面的主數據
msg：返回成功或者失敗的錯誤信息
返回數據中的狀態碼、狀態信息，常指具體的業務狀態，不建議和 HTTP 狀態碼混在一起。HTTP 狀態，是用來體現 HTTP鏈路狀態情況，如：404-Not Found。HTTP 狀態碼和 JSON 結果中的狀態碼，並存尚可，用於體現不同維度的狀態。
簡單的功能如下：
這里不牽扯到任何 Python 和 Pycharm 的教學，不會的童鞋挪步 Python 開發教程。
參考新浪開放平台 https://open.weibo.com ，基本是國內最為標準的 API 文檔之一。