1. 程式人生 > 其它 >web應用模式、API相關、RESTful API規範

web應用模式、API相關、RESTful API規範

目錄

Web應用模式

前後端混合開發

像之前開發的bbs專案,使用render(request, 'index.html')類似這種,頁面的渲染都是在後臺完成的,包括用的模板語法,後端人員要寫CSS,JS,HTML。

前後端分離開發

前後端分離開發現在是主流的方式,前端發展出一些框架(vue,react),前端人員用JS的的DOM操作,在頁面中插入內容,頁面的渲染只在前端完成。以後前端人員只負責寫前端,後端人員只負責寫後端。這樣的好處是前端可以是不同的展現方式,可以是網頁,可以是app,小程式。

API介面

為了在團隊內部形成共識、防止個人習慣差異引起的混亂,我們需要找到一種大家都覺得很好的介面實現規範,而且這種規範能夠讓後端寫的介面,用途一目瞭然,減少雙方之間的合作成本。

通過網路,規定了前後臺資訊互動規則的url連結,也就是前後臺資訊互動的媒介

Web API介面和一般的url連結還是有區別的,Web API介面簡單概括有下面四大特點

  • url:長得像返回資料的url連結

  • 請求方式:get、post、put、patch、delete

    • 採用get方式請求上方介面
  • 請求引數:json或xml格式的key-value型別資料

    • ak:6E823f587c95f0148c19993539b99295
    • region:上海
    • query:肯德基
    • output:json
  • 響應結果:json或xml格式的資料

    • 上方請求引數的output引數值決定了響應資料的格式

    • 資料

      # xml格式
      https://api.map.baidu.com/place/v2/search?ak=6E823f587c95f0148c19993539b99295&region=%E4%B8%8A%E6%B5%B7&query=%E8%82%AF%E5%BE%B7%E5%9F%BA&output=xml
      #json格式
      https://api.map.baidu.com/place/v2/search?ak=6E823f587c95f0148c19993539b99295&region=%E4%B8%8A%E6%B5%B7&query=%E8%82%AF%E5%BE%B7%E5%9F%BA&output=json
      {
          "status":0,
        	"message":"ok",
          "results":[
              {
                  "name":"肯德基(羅餐廳)",
                  "location":{
                      "lat":31.415354,
                      "lng":121.357339
                  },
                  "address":"月羅路2380號",
                  "province":"上海市",
                  "city":"上海市",
                  "area":"寶山區",
                  "street_id":"339ed41ae1d6dc320a5cb37c",
                  "telephone":"(021)56761006",
                  "detail":1,
                  "uid":"339ed41ae1d6dc320a5cb37c"
              }
            	...
      		]
      }
      

介面測試工具:Postman

Postman是一款介面除錯工具,是一款免費的視覺化軟體,同時支援各種作業系統平臺,是測試介面的首選工具。

Postman可以直接從官網:https://www.getpostman.com/downloads/下載獲得,然後進行傻瓜式安裝。

  • 工作面板

  • 簡易的get請求

  • 簡易的post請求
  • 案例:請求百度地圖介面

RESTful API規範

RESTful是一種定義Web API介面的設計風格,尤其適用於前後端分離的應用模式中。

這種風格的理念認為後端開發任務就是提供資料的,對外提供的是資料資源的訪問介面,所以在定義介面時,客戶端訪問的URL路徑就表示這種要操作的資料資源。

事實上,我們可以使用任何一個框架都可以實現符合restful規範的API介面。

資料的安全保障

  • url連結一般都採用https協議進行傳輸

    注:採用https協議,可以提高資料互動過程中的安全性

介面特徵表現

多版本共存

  • 在url連結中標識資料版本

    注:url連結中的v1、v2就是不同的資料版本的提現

    -有的人用了老版本app--》老介面v1
    -有的人用了新版本app--》新介面v2

資料即是資源,均使用名詞(可複數)

資源操作由請求方式決定(method)

過濾,通過在url上傳參的形式傳遞搜尋條件

響應狀態碼

正常響應

  • 響應狀態碼2xx
    • 200:常規請求
    • 201:建立成功

重定向響應

  • 響應狀態碼3xx
    • 301:永久重定向
    • 302:暫時重定向

客戶端異常

  • 響應狀態碼4xx
    • 403:請求無許可權
    • 404:請求路徑不存在
    • 405:請求方法不存在

伺服器異常

  • 響應狀態碼5xx
    • 500:伺服器異常

響應體中的狀態碼

從響應體中返回的json格式資料也有狀態碼,比如code或status,這是服務端自定義的狀態碼

比如1001:使用者名稱錯誤, 1002:沒有許可權。

錯誤處理,應返回錯誤資訊,error當做key

{
    error: "無許可權操作"
}

返回資料格式符合如下規範(大部分公司不按這個)

GET /collection:返回資源物件的列表(陣列)
GET /collection/resource:返回單個資源物件
POST /collection:返回新生成的資源物件
PUT /collection/resource:返回完整的資源物件
PATCH /collection/resource:返回完整的資源物件
DELETE /collection/resource:返回一個空文件

返回資源中連結地址

{
      "id": 1404376560,
      "description": "人生五十年,乃如夢如幻;有生斯有死,壯士復何憾。",
      "url": "http://blog.sina.com.cn/zaku",
      "profile_image_url": "http://tp1.sinaimg.cn/1404376560/50/0/1",
      "domain": "zaku",
  }

比較好的介面返回

# 響應資料要有狀態碼、狀態資訊以及資料本身
{
  	"status": 0,
  	"msg": "ok",
  	"results":[
        {
            "name":"肯德基(羅餐廳)",
            "location":{
                "lat":31.415354,
                "lng":121.357339
            },
            "address":"月羅路2380號",
            "province":"上海市",
            "city":"上海市",
            "area":"寶山區",
            "street_id":"339ed41ae1d6dc320a5cb37c",
            "telephone":"(021)56761006",
            "detail":1,
            "uid":"339ed41ae1d6dc320a5cb37c"
        }
      	...
		]
}