改進 Go 微服務中的請求、驗證和回應處理

本指南解釋了我如何簡化 Go 微服務中請求、驗證和回應的處理，旨在實現簡單性、可重用性和更易於維護的程式碼庫。

介紹

我在 Go 中使用微服務已經有一段時間了，我一直很欣賞這種語言提供的清晰度和簡單性。我最喜歡 Go 的事情之一是幕後沒有發生任何事情；程式碼始終是透明且可預測的。

但是，開發的某些部分可能非常乏味，尤其是在驗證和標準化 API 端點中的回應時。我嘗試了許多不同的方法來解決這個問題，但最近，在編寫 Go 課程時，我想到了一個相當意想不到的想法。這個想法為我的訓練員增添了一絲“魔力”，令我驚訝的是，我喜歡它。透過這個解決方案，我能夠集中請求的驗證、解碼和參數解析的所有邏輯，並統一 API 的編碼和回應。最終，我在保持程式碼清晰性和減少重複實現之間找到了平衡。

問題

開發 Go 微服務時，常見任務是有效處理傳入的 HTTP 請求。此過程通常涉及解析請求主體、提取參數、驗證資料以及發回一致的回應。讓我用一個例子來說明這個問題：

讓我解釋一下上面的程式碼，重點是我們手動處理的處理程序部分：

• 處理路徑參數：驗證所需的路徑參數是否存在並處理它。
• 解碼請求正文：確保正確解析傳入的 JSON。
• 驗證：使用驗證器包檢查請求欄位是否符合要求標準。
• 錯誤處理：當驗證失敗或JSON格式錯誤時，用適當的錯誤訊息回應客戶端。
• 一致的回應：手動建立響應結構。

雖然程式碼有效，但它涉及大量的樣板邏輯，必須為每個新端點重複這些邏輯，這使得維護更加困難並且容易出現不一致。

那麼，我們該如何改進呢？

分解代碼

為了解決這個問題並提高程式碼的可維護性，我決定將邏輯分為三個不同的層：請求、回應和驗證 。這種方法封裝了每個部分的邏輯，使其可重複使用且更易於獨立測試。

請求層

Request 層負責從傳入的 HTTP 請求中解析和提取資料。透過隔離這個邏輯，我們可以標準化資料的處理方式，並確保所有解析都得到統一處理。

驗證層

驗證層僅專注於根據預定義規則驗證解析的資料。這使驗證邏輯與請求處理分開，使其在不同端點之間更易於維護和重複使用。

響應層

Response 層處理程序回應的建構與格式化。透過集中回應邏輯，我們可以確保所有 API 回應遵循一致的結構，從而簡化偵錯並改善客戶端互動。

所以......雖然將程式碼分成層可以帶來諸如可重用性、可測試性和可維護性之類的好處，但它也帶來了一些權衡。複雜性的增加可能會使新開發人員更難掌握專案結構，而對於簡單的端點，使用單獨的層可能會讓人感覺過度，可能會導致過度設計。了解這些優點和缺點有助於決定何時有效應用此模式。

在一天結束的時候，總是關於最困擾你的事情。正確的？所以，現在讓我們介入我們的舊程式碼並開始實現上面提到的層。

將程式碼重構為層

第 1 步：建立請求層

首先，我們重構程式碼，將請求解析封裝到專用的函數或模組中。此層僅專注於讀取和解析請求主體，確保其與處理程序中的其他職責分離。

建立一個新檔案httpsuite/request.go:

注意：此時，我不得不使用反射。也許我太愚蠢了，找不到更好的等待去做。 ？

當然，我們也可以測試這個，建立測試檔httpsuite/request_test.go:

如您所見，請求層使用驗證層。然而，我仍然希望在程式碼中保持層的分離，不僅是為了更容易維護，而且因為我可能還想使用隔離的驗證層。

根據需要，將來我可能會決定將所有層保持隔離，並透過使用一些介面來允許其相互依賴。

第 2 步：實現驗證層

一旦請求解析被分離，我們就會建立一個獨立的驗證函數或模組來處理驗證邏輯。透過隔離此邏輯，我們可以輕鬆測試它並跨多個端點應用一致的驗證規則。

為此，我們建立 httpsuite/validation.go 檔案：

現在，建立測試檔案httpsuite/validation_test.go:

第 3 步：建立響應層

最後，我們將響應構造重構為一個單獨的模組。這可確保所有回應遵循一致的格式，從而更輕鬆地管理和調試整個應用程式中的回應。

建立檔案httpsuite/response.go:

建立測試檔案httpsuite/response_test.go:

此重構的每一步都允許我們透過將特定職責委託給定義良好的層來簡化處理程序邏輯。雖然我不會在每個步驟中顯示完整的程式碼，但這些變更涉及將解析、驗證和回應邏輯移動到各自的函數或檔案中。

重構範例程式碼

現在，我們需要更改舊程式碼以使用圖層，讓我們看看它會是什麼樣子。

透過將處理程序程式碼重構為請求解析、驗證和回應格式化層，我們成功刪除了先前嵌入處理程序本身的重複邏輯。這種模組化方法不僅提高了可讀性，而且透過保持每個職責的重點和可重用性來增強可維護性和可測試性。現在，處理程序已簡化，開發人員可以輕鬆理解和修改特定層，而不會影響整個流程，從而創建更清晰、更具可擴展性的程式碼庫。

結論

我希望這份關於使用專用請求、驗證和回應層來建立 Go 微服務的逐步指南能夠為創建更清晰、更可維護的程式碼提供深入見解。我很想聽聽您對這種方法的想法。我錯過了什麼重要的事情嗎？您將如何在自己的專案中擴展或改進這個想法？

我鼓勵您探索原始程式碼並直接在專案中使用httpsuite。您可以在 rluders/httpsuite 儲存庫中找到該庫。您的回饋和貢獻對於使這個函式庫對 Go 社群更加強大和有用來說非常寶貴。

大家下期見。

以上是改進 Go 微服務中的請求、驗證和回應處理的詳細內容。更多資訊請關注PHP中文網其他相關文章！