亚洲视频二区_亚洲欧洲日本天天堂在线观看_日韩一区二区在线观看_中文字幕不卡一区

公告:魔扣目錄網為廣大站長提供免費收錄網站服務,提交前請做好本站友鏈:【 網站目錄:http://www.430618.com 】, 免友鏈快審服務(50元/站),

點擊這里在線咨詢客服
新站提交
  • 網站:51998
  • 待審:31
  • 小程序:12
  • 文章:1030137
  • 會員:747

設計一個直觀且用戶友好的RESTful API往往是一項艱巨的工作。而對于初次嘗試規劃和管理API生命周期的新手開發者而言,尤為如此。下面,我將以簡單示例的形式,和您探討如何循序漸進地管理RESTful API的生命周期。

 

初始階段

讓我們首先來看一個典型的Hello應用代碼的示例:

> curl http://org. apisix/hello
Hello world
> curl http://org. apisix/hello/Joe
Hello Joe

如下圖所示,我們不必了解其底層技術,只需專注其API部分即可。

 

采用API網關

首先也是最關鍵的一步:禁止將應用直接暴露到互聯網上,并在前端建立一個API網關。維基百科是這樣定義API網關的:作為一個API的服務器前端,它能夠收到各種API請求,并通過實施節流和安全策略,將請求傳遞給后端服務,進而將響應回傳給請求者。

網關通常包括一個用于編排和修改請求與響應轉換引擎。同時,網關還可以提供諸如:收集分析數據、提供緩存、支持身份驗證、授權、安全審計以及合規檢查等功能。當然,如果您不太熟悉API網關的概念,也可以直接把它理解為一個更高級別的反向代理。在此,我將使用 Apache APISIX? ?,您也可以使用自己熟悉的網關。

為了暴露網關,您需要更新指向網關的DNS記錄,并向外廣播。您既可以等待一段時間讓其自動更新,也可以通過? ?dnschecker? ?來加速這個過程。

我使用APISIX創建了一個將HTTP請求發送到網關的路由(route,請參見如下代碼段)。

curl http://apisix:9080/apisix/admin/routes/1 -H 'X-API-KEY: xyz' -X PUT -d ' # 1-2
{
  "name": "Direct Route to Old API",               # 3
  "methods": ["GET"],                              # 4
  "uris": ["/hello", "/hello/", "/hello/*"],       # 5
  "upstream": {                                    # 6
    "type": "roundrobin",                          # 8
    "nodes": {
      "oldapi:8081": 1                             # 7
    }
  }
}'

注釋:

1. APISIX會分配一個自動生成的ID(您也可以使用現成的)。在此,我使用現成的,并使用put將它傳遞給URL - 1。

2. 通過API key來更新路由。

3. 雖然我們不一定需要命名路由,但它能夠讓我們更好地對其有所了解。

4. 針對路由的HTTP方法數組。

5. 針對路由的URL數組。

6. 指明后端應用的上游(upstream)。在本例中,即為Hello World API。

7. 各個節點的Hashmap都自帶有權重。顯然,權重只有存在多個節點時才有意義。

8. 針對多個節點配置均衡算法。

 

如上圖所示,您可以通過如下方式查詢網關,并得到相同的結果:

> curl http://org. apisix/hello
Hello world
> curl http://org. apisix/hello/Joe
Hello Joe

API的版本

開發一個API往往意味著會出現其多個版本共存的情況。我們可以用如下三種方式給API編制版本:

  • 查詢參數:

curl http://org. apisix/hello?version=1

curl http://org. apisix/hello?version=2

  • 標頭:

curl -H 'Version: 1' http://org. apisix/hello

curl -H 'Version: 2' http://org. apisix/hello

  • 路徑:

curl http://org. apisix/v1/hello

curl http://org. apisix/v2/hello

在此,我將使用目前廣為采用的基于路徑的版本編制方法。當然,APISIX也支持其他兩種方式。

在前文中,我們創建了一個包含上游信息的路由。同時,APISIX也允許我們創建一個帶有專屬ID的上游,以重用其多個路由:

curl http://apisix:9080/apisix/admin/upstreams/1 -H 'X-API-KEY: xyz' -X PUT -d ' # 1
{
  "name": "Old API",                                                             # 2
  "type": "roundrobin",
  "nodes": {
    "oldapi:8081": 1
  }
}'

注釋:

1. 使用upstreams路徑

2. 針對新的上游的有效載荷

由于上游只知道/hello,不知道/v1/hello,因此在轉發至上游之前,我們仍需要重寫發往網關的查詢。APISIX可以通過插件來實現此類轉換和過濾。下面,讓我們創建一個用于重寫路徑的插件配置:

curl http://apisix:9080/apisix/admin/plugin_configs/1 -H 'X-API-KEY: xyz' -X PUT -d ' # 1
{
  "plugins": {
    "proxy-rewrite": {                                        # 2
      "regex_uri": ["/v1/(.*)", "/$1"]                        # 3
    }
  }
}'

注釋:

1. 使用plugin-configs路徑

2. 使用? ?proxy-rewrite? ?插件

3. 刪除版本的前綴

現在我們就可以通過如下代碼段,創建有版本的路由,以引導新創建的上游和插件配置:

curl http://apisix:9080/apisix/admin/routes/2 -H 'X-API-KEY: xyz' -X PUT -d '  # 1
{
  "name": "Versioned Route to Old API",
  "methods": ["GET"],
  "uris": ["/v1/hello", "/v1/hello/", "/v1/hello/*"],
  "upstream_id": 1,
  "plugin_config_id": 1
}'

下面展示了新路由的邏輯圖。

 

在此,我們已配置了有版本和非版本的兩個路由:

> curl http://org. apisix/hello
Hello world
> curl http://org. apisix/v1/hello
Hello world

將用戶從非版本路徑遷移到有版本路徑

雖然我們給API編制了版本,但是用戶可能仍會使用舊的、非版本的API。畢竟,我們肯定不能在用戶不知情時就刪除掉舊的路由,而只能通過HTTP的301狀態代碼,讓用戶知道資源已經從http://org.apisix/hello遷移到了

http://org.apisix/v1/hello。如下代碼段展示了? ?如何通過配置重定向插件? ?來初始化路由:

curl http://apisix:9080/apisix/admin/routes/1 -H 'X-API-KEY: xyz' -X PATCH -d '
{
  "plugins": {
    "redirect": {
      "uri": "/v1$uri",
      "ret_code": 301
    }
  }
}'

 

其運行結果如下:

>curl http://apisix. org/hello
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>openresty</center>
</body>
</html>
>curl -L apisix:9080/hello                     # 1
Hello world

注釋:

1. -L選項后面跟著重定向

根據規則,用戶要么透明地使用到了新的端點,要么收到301的狀態提示,使用新的API位置。

識別用戶

您可能已經注意到,我們并不知道誰會使用我們的API。因此,為了保證API在被調用的過程中不會中斷用戶的使用,我選擇了限制未注冊的用戶可調用的數量。如果他們的總量到達了該限制,我們將返回典型的HTTP 429狀態消息,要求他們完成注冊。

當然,目前尚無開箱即用的插件可以實現這一點。因此,我在APISIX中引入Lua引擎,并用Lua編寫出了相應的插件。您可以通過GitHub的鏈接

--https://github.com/nfrankel/evolve-apis/blob/master/unauth-limit-plugin/src/unauth-limit.lua,來瀏覽其源代碼。當然,您也可以使用Python/ target=_blank class=infotextkey>Python、WebAssembly或任何基于JVM的語言,來編寫自己的插件。

我將通過如下步驟來完成插件的加載:

1. 配置APISIX使用的目錄:

apisix: extra_lua_path:/opt/apisix/.lua ?”

注意:APISIX可以使用位于/opt/apisix/文件夾下的任何Lua腳本。

2. 加載插件:

由于APISIX支持熱重載,因此它可以在無需重新啟動的情況下添加額外的插件。

curl http://apisix:9080/apisix/admin/plugins/reload -H 'X-API-KEY: xyz' -X PUT

3. 給現有插件的配置打補丁:

最后,我們需要為插件本身更新專屬的配置:

curl http://apisix:9080/apisix/admin/plugin_configs/1 -H 'X-API-KEY: xyz' -X PATCH -d '
{
  "plugins": {
    "proxy-rewrite": {                                # 1
      "regex_uri": ["/v1/(.*)", "/$1"]
    },
    "unauth-limit": {                                 # 2
      "count": 1,                                     # 3
      "time_window": 60,                              # 3
      "key_type": "var",                              # 4
      "key": "consumer_name",                         # 4
      "rejected_code": 429,
      "rejected_msg": "Please register at https://apisix. org/register to get your API token and enjoy unlimited calls"
    }
  }
}'

注釋:

1. 我們需要重復現有的插件配置。當然,APISIX團隊正在修復這個bug。

2. 指向我們的插件。

3. 對于已通過認證的用戶,插件可限制每60秒超過一個調用。

4. 我會在下一節中解釋到。

我們通過如下命令檢查其是否能夠按預期運行:

>curl apisix:9080/v1/hello
Hello world
>curl apisix:9080/v1/hello
{"error_msg":"Please register at https://apisix. org/register to get your API token and enjoy unlimited calls"}

實際上確實如此。

用戶認證

接著,我們需要為消費者(consumer)角色配置一個專屬的身份驗證插件。目前,我們可以選用的此類身份驗證插件有:API key、JWT、OpenId、LDAP、以及Keycloak等。在本例中,我們采用APISIX的? ?key-auth? ?插件。下面,讓我們配置一個通過API key驗證的消費者對象:

curl http://apisix:9080/apisix/admin/consumers -H 'X-API-KEY: xyz' -X PUT -d '
{
  "username": "johndoe",                 # 1
  "plugins": {
    "key-auth": {                        # 2
      "key": "mykey"                     # 3
    }
  }
}'

注釋:

1. 消費者的ID

2. 可供使用的插件

3. 有效令牌--mykey

注意,其默認的標頭為apikey,你也可以配置為其他,具體請參見key-auth插件的? ?相關文檔? ?。

我們用如下命令來驗證其是否能夠按照我們的需求運行:

>curl -H 'apikey: mykey' apisix:9080/v1/hello
Hello world
>curl -H 'apikey: mykey' apisix:9080/v1/hello
Hello world

在生產環境中測試

至此,我們的改進版Hello world API便可以供用戶調用了。如您所見,部署一個新的、可能包含潛在錯誤的應用版本,往往會給生產環境和業務營收帶來負面的影響。為了盡量減少此類風險,我們可以采用金絲雀發布策略,即:先對一小部分用戶推出新的軟件版本,然后慢慢地擴展到生產環境中的所有用戶處。如果出現了故障,那么新版本只會影響一小部分的用戶群,我們能夠及時回滾到舊的版本。就API網關而言,我們可以復制生產環境的流量到新的API端點上,實現在對用戶幾乎不產生影響的情況下,盡早發現更多的缺陷。

在此,APISIX提供了? ?proxy-mirror插件? ?,可向其他節點發送復制的生產環境流量。對此,我們可以對插件配置做如下更新:

curl http://apisix:9080/apisix/admin/plugin_configs/1 -H 'X-API-KEY: xyz' -X PATCH -d '
{
 "plugins": {
    "proxy-rewrite": {
      "regex_uri": ["/v1/(.*)", "/$1"]
    },
    "unauth-limit": {
      "count": 1,
      "time_window": 60,
      "key_type": "var",
      "key": "consumer_name",
      "rejected_code": 429,
      "rejected_msg": "Please register at https://apisix. org/register to get your API token and enjoy unlimited calls"
    },
    "proxy-mirror": {
      "host": "http://new. api:8082"                             # 1
    }
  }
}'

注釋:

1. APISIX將發送流量到該地址上。

 

根據上圖,我們可以監控和比較新和舊端點,一旦發生錯誤,我們便可以修復錯誤,并重新部署。在此,我們首先通過如下命令,創建一個指向新的API的上游:

curl http://apisix:9080/apisix/admin/upstreams/2 -H 'X-API-KEY: xyz' -X PUT -d '
{
  "name": "New API",
  "type": "roundrobin",
  "nodes": {
    "newapi:8082": 1
  }
}'

然后,我們可以使用? ?traffic-split? ?,來更換proxy-mirror插件:

curl http://apisix:9080/apisix/admin/plugin_configs/1 -H 'X-API-KEY: xyz' -X PATCH -d '
{
 "plugins": {
    "proxy-rewrite": {
      "regex_uri": ["/v1/(.*)", "/$1"]
    },
    "unauth-limit": {
      "count": 1,
      "time_window": 60,
      "key_type": "var",
      "key": "consumer_name",
      "rejected_code": 429,
      "rejected_msg": "Please register at https://apisix. org/register to get your API token and enjoy unlimited calls"
    },
    "traffic-split": {
      "rules": [
        {
          "weighted_upstreams": [      # 1
            {
              "upstream_id": 2,
              "weight": 1
            },
            {
              "weight": 1
            }
          ]
        }
      ]
    }
  }
}'

注釋:

1. 作為演示,我們將50%的流量發送到新的API。在真實環境中,您可能只會配置少數的內部用戶去使用新的端點。

curl -L -H 'apikey: mykey' apisix:9080/hello
Hello world
curl -L -H 'apikey: mykey' apisix:9080/hello
Hello world (souped-up version!)

如果一切工作正常,我們可以將逐漸增加的流量移至新的API。最終我們可以移除traffic split,將默認端點從v1重定到v2上。

棄用舊的版本

根據IETF的草案規范,我們可以基于特定的HTTP響應標頭,來棄用HTTP的標頭字段 (請參見

--https://tools.ietf.org/id/draft-dalal-deprecation-header-03.html)。即:在API網關的幫助下,我們可以通過配置路由,來與有待棄用和替代的版本進行通信。為此,我們將使用由APISIX提供? ?response-rewrite? ?,來添加額外棄用標志標頭,請參見如下代碼段:

curl -v http://apisix:9080/apisix/admin/plugin_configs/1 -H 'X-API-KEY: xyz' -X PATCH -d '
{
 "plugins": {
    "proxy-rewrite": {
      "regex_uri": ["/v1/(.*)", "/$1"]
    },
    "unauth-limit": {
      "count": 1,
      "time_window": 60,
      "key_type": "var",
      "key": "consumer_name",
      "rejected_code": 429,
      "rejected_msg": "Please register at https://apisix. org/register to get your API token and enjoy unlimited calls"
    },
    "response-rewrite": {
      "headers": {
        "Deprecation": "true",
        "Link": "<$scheme://apisix:$server_port/v2/hello>; rel="successor-version""
      }
    }
  }
}'
curl -v -H 'apikey: mykey' apisix:9080/v1/hello
< HTTP/1. 1 200 
< Content-Type: text/plain;charset=UTF-8
< Content-Length: 11
< Connection: keep-alive
< Date: Fri, 18 Feb 2022 16:33:30 GMT
< Server: APISIX/2. 12. 0
< Link: <http://apisix:9080/v2/hello>; rel="successor-version"
< Deprecation: true
< 
Hello world

小結

回顧一下,我們按照如下流程向您展示了如何通過循序漸進的過程,來管理API的整個生命周期。

1. 不要直接暴露您的API,而是在前端建立一個API網關

2. 使用路徑、查詢參數、以及請求標頭給現有的API編制版本

3. 通過使用301狀態碼,將用戶從無版本的端點遷移到有版本處

4. 識別和認證用戶

5. 為了測試生產環境,我們先復制流量,再將小部分用戶遷移到新的版本上

6. 發布新的版本

7. 通過標準響應標頭來棄用舊的版本

分享到:
標簽:RESTful
用戶無頭像

網友整理

注冊時間:

網站:5 個   小程序:0 個  文章:12 篇

  • 51998

    網站

  • 12

    小程序

  • 1030137

    文章

  • 747

    會員

趕快注冊賬號,推廣您的網站吧!
最新入駐小程序

數獨大挑戰2018-06-03

數獨一種數學游戲,玩家需要根據9

答題星2018-06-03

您可以通過答題星輕松地創建試卷

全階人生考試2018-06-03

各種考試題,題庫,初中,高中,大學四六

運動步數有氧達人2018-06-03

記錄運動步數,積累氧氣值。還可偷

每日養生app2018-06-03

每日養生,天天健康

體育訓練成績評定2018-06-03

通用課目體育訓練成績評定