❶ restful api介面規范是什麼
REST（REpresentationStateTransfer）描述了一個架構樣式的網路系統，比如web應用程序。
一般依賴於HTTP認證，HTTP認證有幾種：basic，digest，token，這些都有標準的實現的開源包需要主要的是這個認證的帳號跟你業務的帳戶實際是不一樣的。REST屬於webService一種，安全是後台服務的安全，因此不需要實際的業務帳號，通常是系統keyStore證書庫里的賬戶。
RESTFUL特點包括：
1、每一個URI代表1種資源。
2、客戶端使用GET、POST、PUT、DELETE4個表示操作方式的動詞對服務端資源進行操作：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源。
3、通過操作資源的表現形式來操作資源。
4、資源的表現形式是XML或者HTML。
5、客戶端與服務端之間的交互在請求之間是無狀態的，從客戶端到服務端的每個請求都必須包含理解請求所必需的信息。
❷ RESTful介面詳解
REST是英文representational state transfer(表象性狀態轉變)或者表述性狀態轉移;Rest是web服務的一種架構風格;使用HTTP,URI,XML,JSON,HTML等廣泛流行的標准和協議;輕量級,跨平台,跨語言的架構設計;它是一種設計風格,不是一種標准,是一種思想
Rest架構的主要原則：
符合REST原則的架構方式即可稱為RESTful
什麼是Restful:
對應的中文是rest式的;Restful web service是一種常見的rest的應用,是遵守了rest風格的web服務;rest式的web服務是一種ROA(The Resource-Oriented Architecture)(面向資源的架構).
為什麼會出現Restful
在Restful之前的操作：
http://127.0.0.1/user/query/1 GET 根據用戶id查詢用戶數據
http://127.0.0.1/user/save POST 新增用戶
http://127.0.0.1/user/update POST 修改用戶信息
http://127.0.0.1/user/delete/1 GET/POST 刪除用戶信息
RESTful用法：
http://127.0.0.1/user/1 GET 根據用戶id查詢用戶數據
http://127.0.0.1/user POST 新增用戶
http://127.0.0.1/user PUT 修改用戶信息
http://127.0.0.1/user DELETE 刪除用戶信息
之前的操作是沒有問題的,大神認為是有問題的,有什麼問題呢?你每次請求的介面或者地址,都在做描述,例如查詢的時候用了query,新增的時候用了save,其實完全沒有這個必要,我使用了get請求,就是查詢.使用post請求,就是新增的請求,我的意圖很明顯,完全沒有必要做描述,這就是為什麼有了restful.
如何使用:
SpringMVC實現restful服務:
SpringMVC原生態的支持了REST風格的架構設計
所涉及到的註解:
---@RequestMapping
---@PathVariable
---@ResponseBody
HTTP相應狀態碼:
❸ 微信小程序上線後請求介面總是失敗
本地小程序開發工具測試請求介面都很正常，使用預覽和真機調試功能在手機上運行請求介面總是失敗。
小程序上線後，部分手機請求介面正常，部分手機請求介面失敗，將請求介面復制到谷歌瀏覽器中查詢總是成功的。
restful 介面定義為： https://ip:port/bus/:router_name ，其中 router_name 是個變數。實際請求介面為： https://ip:port/bus/993路 ，可以看到：請求地址中的變數 router_name 被 993路 給替換了。問題就出在這里， 請求地址中含有中文 。
在 小程序開發工具 、 谷歌瀏覽器 和 部分請求成功的手機 上最終發出的請求都會對請求地址中的中文漢字進行編碼，如下：
在 開發工具中預覽功能 、 開發工具中真機調試功能 和 部分請求不成功的手機 上最終發出的請求並不會對中文進行編碼，如下：
上面分析了請求介面失敗是因為部分手機沒有對請求地址中的中文進行編碼，解決方法為利用 js 自帶的 api encodeURIComponent() 處理。
有一點需要注意：不能對整個請求地址進行編碼，那麼的話會對所有除字母、數字以外的符號進行編碼，會變成下面這樣，實際請求中仍然會報錯。
在處理 restful 介面過程中，有一步用具體指（如： 991路 ）替換請求地址中的變數（如： https://ip:port/bus/:router_name 中的 :router_name ），此時先對 991路 進行編碼再替換變數值即可。
❹ 如何理解rest和restful，什麼是restfulAPI
簡單理解一
就是用URL定位資源，用HTTP描述操作。
簡單理解二
URL定位資源，用HTTP動詞(GET,POST,DELETE,DETC)描述操作。
官方定義
一種軟體架構風格、設計風格，而不是標准，只是提供了一組設計原則和約束條件。它主要用於客戶端和伺服器交互類的軟體。基於這個風格設計的軟體可以更簡潔，更有層次，更易於實現緩存等機制。
以web開發舉例
在設計web介面的時候，REST主要是用於定義介面名，介面名一般是用名次寫，不用動詞，那怎麼表達「獲取」或者「刪除」或者「更新」這樣的操作呢——用請求類型來區分。
比如，我們有一個students介面，對於「學生」我們有增刪改查四種操作，怎麼定義REST介面？
增加一個學生，uri: http://testcode.com/school/students 介面類型：POST
刪除一個朋友，uri: http://testcode.com/school/students 介面類型：DELETE
修改一個朋友，uri: http://testcode.com/school/students 介面類型：PUT
查找朋友，uri: http://testcode.com/school/students 介面類型：GET
上面我們定義的四個介面就是符合REST協議的，請注意，這幾個介面都沒有動詞，只有名詞students，都是通過Http請求的介面類型來判斷是什麼業務操作。
舉個反例
uri: http://testcode.com/school/addStudents 該介面用來表示增加學生，這就是不符合REST協議的介面。
建議
用HTTP Status Code傳遞Server的狀態信息。比如最常用的 200 表示成功，500 表示Server內部錯誤，403表示Bad Request等。(反例：傳統web開發返回的狀態碼一律都是200，其實不可取。)
REST風格介面意義
前後端分離。前端拿到數據只負責展示和渲染，不對數據做任何處理。後端處理數據並以JSON格式傳輸出去，定義這樣一套統一的介面，在web，ios，android三端都可以用相同的介面，節約開發成本以及便於同一調試。
❺ django-restful:與前端vue介面對接
category 與vue 介面對接
首先是需要把所有的category的內容取出來
由於前端vue展示category是分級的
一級 二級 三級 這樣展示的
所以我們需要把三個內容都拿出來
但是首先需要取出第一級 然後第一級鑲嵌了第二級，然後第二級鑲嵌第三季 ，就跟上面goods中顯示外鍵的category的內容一樣
我們還是需要寫serializer
這樣就是一級 鑲嵌二級 二級鑲嵌三級
但是這里有一個問題不要搞錯了 這三個類的位置不能弄錯了
因為一級是調用二級 所以二級一定是先寫好了的
所以二級一定在一級上面 同理 三級要在二級上面
然後就是view
在過濾中加上category_type = 1 這樣就可以直接顯示第一大類 然後第一大類中有第二小類 這樣更有層次感 如果直接一下子全部取出來 就不好分辨了
同時我們還要處理取出某個單一的信息
所以 我們繼承了mixins.RetrieveModelMixin 這個類，這是一個顯示詳情的類
例如顯示某個動物園的某個動物那樣
/zoos/id
這樣的url
同樣這樣寫了 我們就直接只配置category的url就夠了
就不用考慮 後面的id是否還需要配置一個url 這些都不用考慮了，因為我們繼承了 viewset這個類
這些問題他都幫我們解決了
這樣處理我們後端就能看見了
但是這樣處理了 前端對接時 會發現 無法顯示
因為有一個跨域問題
這個問題前後端 都可以獨自解決 這里學習的是後端，所以講一下後端的做法
就是修改服務端
在github上搜索django-cors-headers就可以找到這個信息
同樣裡面介紹如何使用
安裝
pip install django-cors-headers
然後settins中INSTALLED_APPS配置和settings中MIDDLEWARE配置
這里要注意 MIDDLEWARE配置中
'corsheaders.middleware.CorsMiddleware',
'django.middleware.common.CommonMiddleware',
這兩個必須放在
'django.middleware.csrf.CsrfViewMiddleware',
這個的前面 不然會報錯
同時還要配置
CORS_ORIGIN_ALLOW_ALL = True
允許跨域訪問 它默認是False
這樣前端就可以正常顯示了
為什麼會產生跨域訪問
因為vue中api配置的中 我們調試數據 不可能把所有的host 都修改了 有一些是線上數據 我們調試的是本地的一部分數據 所以要重新定一個localhost
修改部分 host的鏈接
這樣就導致了跨域 本身使用的是一個線上host埠，但是數據中有一部分是請求的是本地host埠 導致了跨域訪問
❻ 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 文檔之一。