添加延遲和錯誤代碼 - 在C#課程中構建一個示例API

樣本API及其目的介紹

Tim從重申擁有一個樣本API在學習網頁開發時的重要性開始本課。 這樣的API為您的前端應用程式提供具體的測試對象。

在本課結束時，Tim的目標是構建一個強大的API，其中包括：

• 樣本數據

• 文件

• 健康檢查

• 模擬延遲

• 模擬錯誤

• 通過Docker和VPS的部署選項

在這一特定課程中，Tim專注於模擬延遲和生成錯誤代碼，以在不利條件下實現現實的API行為。

為API端點添加人工延遲

Tim 首先為特定的API端點添加了一個可選的延遲參數——特別是那些處理課程數據的端點。 他的目標是模擬緩慢的API響應，以便更好地進行前端測試。

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

測試延遲機制

Tim 使用Postman（或Postman 克隆）進行了一些測試以驗證延遲邏輯。 例如：

• 延遲=5000（5秒）導致API在返回結果之前暫停。

• 延遲=500導致較短的暫停。

他觀察到，由於處理開銷，實際的延遲將始終稍長於指定的值——這是一個重要的現實世界的細微差別。 正如Tim在5:09所指出的，您不是在計時API到毫秒，而是在模擬一個閾值。

將延遲功能擴展到更多端點

Tim並不止步於"加載所有課程"端點。 他希望保持一致，因此他在"按ID加載課程"端點中實施了相同的延遲功能。

在6:15，他遇到了一個障礙：由於在轉為異步時自動添加了"Async"到方法名稱而導致名稱衝突。 Tim調整了兩個方法名稱以符合Async命名約定，以保持清晰和一致性。

測試確認了實現：

• 延遲被尊重。

• 不存在的記錄在延遲後按預期返回404。

• 刪除延遲或傳遞空值時表現正常，Tim注意到Postman中的UI特徵而非API本身的問題(8:00)。

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

測試錯誤端點

Tim現在通過傳遞各種狀態碼來測試錯誤端點：

• 400 返回"Bad Request"

• 401 返回"Unauthorized"

• 404 返回"Not Found"

• 301 返回"Moved Permanently"

• 405 返回"Method Not Allowed"

這顯示了該端點的靈活性——不僅是錯誤代碼，還包括任何HTTP狀態碼。 在13:04，Tim確認這種方法是測試前端應用程序如何處理不同伺服器響應的理想方法。

雖然他考慮將其命名為/httpcode，但他為簡化保留/error的名稱，因為它主要用於模擬錯誤條件。

功能增強總結

Tim總結了API的改進：

• 延遲模擬API響應的實際延遲。

• 錯誤模擬提供靈活性，以測試虛擬任何HTTP響應。

• 這些功能使樣本API更健壯，對現實的測試場景來說是無價的。

在14:16，Tim強調這些工具對於測試您的應用程式在不同API狀態下的行為（如延遲響應或各種伺服器錯誤）的重要性。

下一步：將API Docker化

雖然在這個視頻中沒有詳細介紹，但Tim暗示下一步：將API Docker化。 這使開發者能夠在本地以自包含的Docker容器中運行樣本API，從而更易於在不同環境中部署和共享。

結語

Tim在視頻結尾重申了他的承諾，即構建一個包含開發者實際測試需求的現實主義功能的全面樣本API。 這些包括：

• 延遲

• 錯誤

• 健康檢查

• 未來的身份驗證和高級端點計劃

目標非常簡單但強大——為開發者提供一種工具，模擬現實API的特性，使他們的應用程序可靠、可靠且用戶友好。

結論

到本課結束時，觀眾對於如何以及為什麼在API中引入人工延遲和錯誤響應有了更好的理解。Tim Corey的方法是系統化、實用的，直接與現實應用程序測試需求相關。 如果您正在尋找增強API測試的方式，那麼這一課是值得跟隨的優秀資源——現在您知道確切的來源了。

觀看由Tim Corey製作的完整視頻教學以獲得實用指導。