作者： DD - 2月 22, 2023

最近這幾年，愈來愈多的網站改以前後端完全分離的架構來開發，而微服務盛行，許多後端應用、AI服務、甚或是商業邏輯，都改以WebAPI的方式來實作，更別說為數眾多的手機行動裝置App也需要以呼叫後端API的方式與伺服器端溝通，來完成各種功能。

因此，API開發成為最近幾年的顯學，API First也在許多場合被提起。Azure的APIM服務，就在這樣的情況下誕生了。

Azure APIM可以幫我們把企業內部的多組API打散或重新包裝，改以同一個endpoint對外，好讓使用者更方便使用，讓管理者更方便控制與管理。

另外，採用APIM還有一個好處，我們可以隔開用戶和真正的API，這樣除了可以保護後端真正的API，也可以在用戶透過APIM呼叫後端真正的API前，可以對往來(與回覆)的數據做一些加工處理，已達成我們需要的安全性或是API行為的改變，也更容易統一的進行全縣控制…等。

底下影片示範如何建立APIM服務，請注意APIM服務的建立，會花比較長的時間，可能會長達半小時以上:

完成之後，就可以建立好APIM服務了。

建立API集合

建立好APIM服務之後，接著可以在Azure Portal中，建立API集合，前面說過，我們會把實際上開發好的API，先整理成API集合，然後再包裝成產品(Product)，釋出給客戶。

底下的說明，我們將示範如何將現有的API(在具備spec definition的狀況下)，整理成待會要釋出的產品。我們以底下這組微軟官方的測試API為例:
https://conferenceapi.azurewebsites.net?format=json

如果你點選上面這個網址，會發現，它出現的是json格式的API規格:

這是標準的 swagger 2.0規則，一般我們撰寫WebAPI之類的後端API服務，都可以透過工具自動產生這些規格文件。若具備這些規格文件。

你可以直接將API透過Import的方式匯入，請看底下操作影片:

從上面的影片當中，你會看到，我們利用 swagger 的json規格定義，把上面的微軟測試API，重新透過APIM封裝，建立另出了一組 endpoint 。

你可以發現API中有一個 GetSpeakers 方法，當我們運行(呼叫)這個方法，會以JSON格式回傳研討會的所有講師(是的，這是一個舉辦研討會的API)。

你可以重複上面的動作，將企業內開發的不同API，個別整理成一組組的集合，以便於未來透過產品功能上架。

Policies 是我們使用 APIM 一個很重要的原因。

由於APIM隔開了API的 consumer 和 provider，因此，位於中間的APIM可以在真實的API被呼叫的前後，做些手腳，在不改變API原始程式碼的狀況下，微調API的行為與回傳的結果。

這功能非常好用，舉例來說，我們可以在不改變原始程式碼的狀況下，讓API實現以下功能:

以上都是非常常用的 policy，底下網址可以看到預設狀況下，APIM支援的policies:
https://learn.microsoft.com/en-us/azure/api-management/api-management-policies

具體的配置，是透過XML方式來實作:

<policies>
    <inbound>
        <cross-domain />
        <base />
        <find-and-replace from="xyz" to="abc" />
    </inbound>
</policies>

APIM提供了一個環境，讓我們得以針對API來配置上面這樣的XML指令，以便於調整API的行為。(例如上面是把API傳輸內容中任何的xyz換成abc)

底下的影片，展示如何把API當中原本呼叫時有的伺服器資訊移除，以避免使用者得知API的開發技術，降低資安風險:

從上面展示的影片你可以看到，透過APIM，我們可以在不改變程式碼的狀況下，微幅調整API的行為甚至傳遞內容，是一個非常好用的技巧。

.NET Walker