• 通過 Header 來做版本控制

# 請求 v1 版本的API
curl  http://httpbin.org/orders -H "custom-version: v1"

# 請求 v2 版本的API
curl  http://httpbin.org/orders -H "custom-version: v2"

作為一個動態(tài)、實時、高性能的 API 網(wǎng)關(guān)，Apache APISIX 可以在任何 RESTful API 服務(wù)上運行，并使用插件來添加新的服務(wù)和擴展其功能，這符合 RESTful 定義中的?Layered system。此外，對于一些沒有遵循 RESTful API 定義的歷史服務(wù)， APISIX 也可以幫你在不改動原有業(yè)務(wù)代碼的情況下完成接口的轉(zhuǎn)換，使你的接口完成?Uniform interface?這一 REST 限制條件，使你的 API 可以更好地遵守 RESTful API 規(guī)范。

分層系統(tǒng)：支持業(yè)務(wù)邏輯和安全邏輯的分割?

你可以只用關(guān)注業(yè)務(wù)邏輯的實現(xiàn)，接口的安全邏輯可以交給 APISIX Authentication 類插件處理，例如?key-auth。APISIX 支持大量的 Authentication 插件，我們以?openid-connet?為例如下圖所示：

我們可以看到，使用 APISIX（API Gateway）在業(yè)務(wù)服務(wù)器前面加一層認(rèn)證邏輯，就可以起到保護上游服務(wù)的作用，讓你的業(yè)務(wù)邏輯和安全邏輯高效解耦。

Layered system：多負載均衡協(xié)議支持?

APISIX 作為 API 網(wǎng)關(guān)，可以設(shè)立在客戶端和服務(wù)端之間，完成不同的負載需求。你甚至可以自定義負載均衡的邏輯。

支持的負載均衡算法有：

• roundrobin: Round robin balancing with weights.
• chash: Consistent hash.
• ewma: Pick the node with minimum latency. See?EWMA Chart?for more details.
• least_conn: Picks the node with the lowest value of (active_conn + 1) / weight. Here, an active connection is a connection being used by the request and is similar to the concept in Nginx.
• user-defined load balancer loaded via require("apisix.balancer.your_balancer")

統(tǒng)一接口：使歷史 API 更加 RESTful?

對于已經(jīng)存在很久的歷史 API，如果沒有很好地遵循 RESTful API 準(zhǔn)則。你可以在不改造原有 API 邏輯的情況下重新通過 APISIX 來封裝新的 API 以滿足不同的業(yè)務(wù)場景。

使用?proxy-rewrite?改寫客戶端請求?

在本文中上方提過我們的路徑中不要有動詞。

例如：歷史版本 API 有 /getOrder 接口，我們可以通過 proxy-rewrite 插件來將 API 請求代理到歷史 API 上：

curl http://127.0.0.1:9080/apisix/admin/routes/1  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "methods": ["GET"],
    "uri": "/orders",
    "plugins": {
        "proxy-rewrite": {
            "uri": "/getOrder",
            "scheme": "http",
        }
    },
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:80": 1
        }
    }
}'

你也可以同樣使用該插件進行 API 版本管理上的操作。

使用?response-rewrite?插件改寫服務(wù)端響應(yīng)?

當(dāng)我們的歷史 API 存在響應(yīng)狀態(tài)碼不規(guī)范時，我們可以通過 response-rewrite 代理 response 響應(yīng)從而達到修改響應(yīng)狀態(tài)碼的目的。

curl http://127.0.0.1:9080/apisix/admin/routes/1  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '

{

    "methods": ["GET"],

    "uri": "/orders",

    "plugins": {

        "response-rewrite": {

            "status_code": 201,

            "body": "{\"code\":\"ok\",\"message\":\"new json body\"}",

            "vars":[

                [ "status","==",200 ]

            ]

        }

    },

    "upstream": {

        "type": "roundrobin",

        "nodes": {

            "127.0.0.1:80": 1

        }

    }

}

例如，這個例子表示將請求?/orders?路徑的 API 中響應(yīng)為?200?的狀態(tài)的請求修改為?201。 APISIX 支持非常豐富的插件，期待你去挖掘更多的玩法。

總結(jié)?

本文詳細說明了什么是 API，什么是 RESTful API 以及其最佳實踐。另外還介紹了如何通過 APISIX 來實現(xiàn)業(yè)務(wù)邏輯和安全邏輯分離，如何使用 APISIX 在不改動原有業(yè)務(wù)代碼的情況下將歷史 API 服務(wù)更加 RESTful。希望本文對你了解 RESTful API 有所幫助，也歡迎你來 GitHub 一起玩耍。

文章來源：Why has RESTful API become the top stream API architecture style?