前情提要

延續[DotnetCore]Refit:類ApiGateway實作文章，筆者在開發前台，後台這種隔離架構時，還會有一個需求是，比較正式的API規格，會有一些客製化的Header值必須要辨別，不外乎就是AcesssToken，或者必要的Client資訊，及封包簽章等資訊，以前台轉發到後台這段來說，猶如上一篇提到透過Refit完成。

筆者的思路是這樣，驗證這些Client Request資訊的職責來說，止於前台，不需要再原封不動將客製化的Header資訊送到後台，因為後台商業邏輯處理來說也不需要這些資訊，因此某些Header的值必須下放到Model層級，讓後台收到的Request中已經含有商業邏輯處理的必要資訊。

再則前台這一層必須要驗證Request的合理性，一定會讀取Header資訊，若要把這些Header資訊原封不動的送到後台，反而還要額外動工，第一是要製作成Refit的參數，第二是後台還要再拆解一次Header資訊，完全是做了很多不需要的步驟，於是乎，這篇就誕生啦。

前情提要

筆者在公司環境開發系統，依照公司規定有一些Secrurity Policy要遵守，尤其是對外站台(前台)，因為是對外開放的站台，按照資安規定，需要完全是一個乾淨的站台，不連資料庫，不做商業邏輯處理，只接收將客戶端傳來的HttpRequest，轉發到商業邏輯處理站台(後台)，因此筆者才在此篇的標題上打上類APIGateway的字言，因為沒有完全符合ApiGateway該有的功能，類似像LoadBalancing、Caching、Retry Policy等重要指標，ApiGateway完整功能可參考https://github.com/ThreeMammals/Ocelot的Features清單就可以略知一二。

前情提要

筆者最近在公司負責開發一個全新的API對外系統，因沒有舊系統包袱，可以設計統一Response，統一的ExceptionHandlerMiddleware，只多不嫌少的各種CustomizeException等等，然而接受客戶端的Request時，勢必要進行Validation作業，可以重捨FluentValidation的懷抱了，此篇就以筆者遇到的情境及解法介紹為主，讓我們看下去吧。

前情提要

筆者在公司負責的系統是跟第三方串接有關的系統，因此經常要串接第三方的API，WebServie，Dll等串接方式，若是API(Http Request)串接則，筆者這邊都全面改用Refit來串接，好處就不再贅述了，即便透過Refit來發Http Request，原本的DotnetCore預設的HttpClient相關的延伸應用，皆可延續使用，以此篇主題來說，筆者這邊想使用Polly做Retry的機制，讓我們繼續看下去。

前情提要

筆者在 [DotnetCore]Refit初體驗那篇中有說到，選擇的Refit的原因有其中一項是可以繼續沿用自定義HttpMessageHandler，此篇就以Refit註冊的同時也掛上自定義HttpMessageHandler的教學。

前情提要

筆者這篇就繼續來介紹Refit的各種用法，依照篇幅會再拆成數篇，筆者會參考官方Document的脈絡，加上筆者已經在工作場合上用到的一些技巧，詳細介紹其用法，好的套件會帶你飛，真的不是說說而已，Refit的API，完全足夠克服於工作場合中遇到的各種挑戰，讓你輕鬆完成Http Request的請求。

前情提要

筆者在上一篇: [DotnetCore]Refit初體驗 ，簡單介紹Refit的使用方式，因上篇中要簡單的呈現，因而透過Linqpad來完成示範，這篇則建立Dotnet Core完整專案，並將Refit套上使用。

前情提要

筆者在公司負責的專案，大多數都跟其他廠商串接有關，串接方式百百種，最多就是Http Request了，因新專案已都使用dotnet 6來開發，透過AddHttpClient註冊，注入HttpClient，再將HttpRequest的實作封裝成HttpClientRepository，確實都滿順利的，但光HttpClient串接也是有百百種，有的廠商要FormPost方式送出RequestContent，有的廠商則一般常見的將RequestContent放在Body，格式方面有些則json格式，有些則xml等等，組合也是挺可怕的多，要一直調整其底層共用程式HttpClientRepository。

再則筆者在實作中遇到一個滿常見的問題，Header重複設定的錯誤，因Http連線成本確實不低，因此透過AddHttpClient使用HttpClient，希望由dotnet底層管理連線，降低其連線成本，以常見的Header設定來說，就屬Authorization了，筆者這邊為了加速往廠商端的查詢，會透過Parallel的方式併發出Request，全部Response都回來後才做商業邏輯處理，因此第一次連線後Header尚未設定的情況下，有一定的機率兩組執行緒碰撞一次，也有一定的機率兩組同時進到判斷式，要新增Header的值，搞得筆者連Lock機制都用上了，目前尚未找到更好的解，只能先這樣暴力解了。最後筆者自己本身在Linqpad上先行測試時會使用HttpRequest相關套件，例:RestSharp，心血來潮認真看了下其API，看到有Headers章節中的API: AddOrUpdateHeader，覺得完全是解決筆者的痛點，突然有一種HttpRequest應該是一個基礎建設，若能有一個套件幫忙實作完成，就可以專心地將所有精力投入在商業邏輯層面就好，進而縮短開發時間，然而某天在LinkedIn貼文上看到一個套件叫[Refit](https://github.com/reactiveui/refit)，不查還好，查完後覺得就它了。

前情提要

筆者負責的專案，是那種到處要跟第三方串接那種，第三方不管是內部或多個外部，串接方式不外乎就是WebService或是Restful API，或者提供dll檔案，多種形式見怪不怪，串接這時候釐清問題是最重要的，因此必須要確保我方系統上保有Request及Response以釐清問題，也是自保的一種概念，因為你無法保證串接的Method跟金額無關，這時候唯有留下系統軌跡才能保證你的清白(被害妄想症上身中)，筆者相信留下紀錄這件事，不管事不是跟別的系統串接，仍是很重要的課題。

然而對於Restful API這種串接方式，最方便留下紀錄了，只要共用一個HttpClientRepository，將發出HttpRequest集中在某一個Method中，方便事後增加其往來紀錄的相關程式碼，當然我方系統是被呼叫方的話，也是可以透過DotnetCore內建的Middleware能搞定。至於呼叫WebService或者dll檔案中的Method則比較傷腦筋一點，動用到今天的主角，AOP Logging，能夠輕鬆地不留痕跡地做到留下紀錄。