https://devblogs.microsoft.com/dotnet/build-test-resilient-apps-dotnet-dev-proxy/
在構建連線到 API 的套用時，我們通常專註於讓套用正常工作。但是，當 API 速度慢、返回錯誤或不可用時會發生什麽？你最不想看到的就是當你的應用程式壞了時，一個憤怒的客戶給你打電話。但是，當你不控制整合的 API 時，很難模擬你的套用將如何處理這些場景。除非您使用 Dev Proxy。
連線到 API 的難點
如今，很難想象一個應用程式沒有連線到 API。我們將 API 用於所有事情：從獲取數據到執行操作。但是，使用 API 不僅僅是發出請求並獲得響應。您使用的 API 無法按預期工作只是時間問題。如果你沒有考慮過，你會給自己帶來麻煩。讓我告訴你怎麽做。
您釋出了一個新的 Web 應用程式，它執行良好。但真的是這樣嗎？
假設您正在構建一個連線到 API 以獲取產品的應用程式。您還可以與外部服務整合以獲取其他產品資訊。在開發中，你使用這兩個 API 的開發版本，只有你和團隊中的其他幾個開發人員使用。您的套用既快速又可靠。它只是工作。然後，將套用部署到生產環境。它一炮而紅。事實上，你的套用非常成功，以至於你整合的外部服務無法再處理負載並開始返回錯誤。您的套用中斷了。客戶不滿意地離開並去找競爭對手。你能預料到這一點嗎？您能否以不同的方式構建套用來處理這種情況？
模擬 API 錯誤和行為（如速率限制或限制）並非不可能，但很難。通常，你無法控制你整合的 API，所以為了模擬它們的不同行為，你最終會編寫復雜的模擬——一堆你不會釋出的程式碼。至少可以說，這是低效的，但這是唯一的方法，不是嗎？差一點。
使用 Dev Proxy 模擬 API 行為
如果我告訴你，有一種方法可以讓你測試你的套用如何處理你連線到的 任何 API 的任何行為，而不必更改套用中的一行程式碼 ，你會怎麽樣？
Dev Proxy 是一個 API 模擬器，可用於模擬不同的 API 行為，而無需更改套用的一行程式碼。沒錯。使用 Dev Proxy，您可以模擬錯誤、延遲、速率限制等。一直以來，您的應用程式都認為它已連線到真正的 API！Dev Proxy 允許你確保套用在連線到的 API 中斷時不會慘遭失敗。憤怒的客戶或客戶經理不再打來電話，要求你放下一切來滅火。
Dev Proxy 是如何工作的？
Dev Proxy 是在開發電腦上本地執行的 Web 代理。在啟動它之前，您可以將其配置為監視對特定 URL 的請求。然後，定義它應該如何處理這些請求：它應該返回預定義的響應、引發錯誤、延遲響應或模擬速率限制，還是其他行為？當您啟動 Dev Proxy 時，它會將自身註冊為您的系統代理，並攔截與您配置的 URL 匹配的所有請求。然後，它會套用您定義的行為。你的套用不知道它沒有與真正的 API 通訊。它只是得到回應，就好像它是一樣。這使它成為測試套用如何處理不同 API 行為的好方法。讓我們看看如何使用 Dev Proxy 在範例 .NET Aspire 套用中模擬 API 行為。
範例案例：使用 Dev Proxy 改進 .NET Aspire 套用
請考慮使用 .NET Aspire 構建的此範例電子商務套用。它由多個服務組成，包括產品目錄的 API。它實作預設的彈性模式。讓我們使用 Dev Proxy 模擬不同的 API 行為來測試預設套用的配置，並提高套用的彈性。
讓我們從啟動應用程式開始，找出產品目錄 API 的 URL。我們將配置 Dev Proxy 以攔截對此 URL 的請求並模擬不同的行為。產品目錄 API 可在 http://localhost:5222 上獲得。
模擬 API 限制
讓我們啟動 Dev Proxy 並將其配置為攔截對此 URL 的所有請求：
devproxy --urls-to-watch 「http://localhost:5222/*」
在此範例中，我們將使用預設的 Dev Proxy 配置，該配置模擬了幾個常見的 API 錯誤，以及延遲和限制。您可以透過其配置檔和它包含的外掛程式集合來控制 Dev Proxy 設定。
現在，讓我們重新啟動 .NET Aspire 套用，將其配置為使用開發代理作為系統代理。它將透過 Dev Proxy 將所有請求路由到產品目錄 API，這將模擬不同的行為。
HTTP_PROXY=http://127.0.0.1:8000 dotnet run --project src/eShop.AppHost/eShop.AppHost.csproj
讓我們從導航到產品目錄開始。報錯啦！
回到終端，我們可以看到 Dev Proxy 模擬了 429 個請求過多的錯誤，指示客戶端回退 5 秒鐘。雖然該應用程式內建了彈性功能，但它還是並列發出多個請求，這使得它看起來不遵循後退並導致 Dev Proxy 使請求失敗。在幾次嘗試呼叫 API 失敗後，套用放棄並在瀏覽器中顯示原始堆疊跟蹤。
我們如何提高套用的彈性以處理這種情況？首先，我們應該考慮捕獲 API 異常並以使用者友好的方式顯示它。它不僅可以幫助我們處理限制，還可以幫助我們處理其他 API 錯誤。我們還應該考慮以不同的方式處理限制，以確保套用正確回退，並讓 API 有時間恢復。
這只是可以使用 Dev Proxy 模擬的一個場景。您還可以模擬其他 API 行為，例如延遲、速率限制等。這樣一來，你就可以測試套用如何處理不同的 API 行為，而無需更改套用的一行程式碼。使用 Dev Proxy 是測試彈性程式碼在最需要時是否按預期工作的好方法。
總結
當您連線到套用中的 API 時，您需要考慮的不僅僅是讓套用正常工作。您使用的 API 失敗只是時間問題。當他們這樣做時，你要確保你的套用能夠正確處理它，並且不會遺失你的客戶數據。Dev Proxy 允許你輕松模擬不同的 API 行為，而無需更改套用的一行程式碼。借助 Dev Proxy，您可以放心地將套用部署到生產環境，而不必擔心在套用出現故障時憤怒的客戶會打電話給您。
在您的應用程式上 試用 Dev Proxy，並親自檢視如何改進它。
參考
安裝 Dev Proxy 工具箱
