前情提要

筆者這篇就繼續來介紹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，能夠輕鬆地不留痕跡地做到留下紀錄。

前情提要

筆者在公司寫後台系統，重回dotnet core MVC的懷抱，不免俗的要搭配jquery來完成前端效果，離筆者好遙遠阿，畢竟在前公司寫angular寫了多年，被model binding的框架養胖了(誤，現在要重頭來蒐集jquery各種套件(武器)的時候了，畢竟筆者要獨力完成一個後台系統，雖然有別的系統可參考，還是個一大挑戰阿。筆者公司的後台系統使用Admin LTE 3的版本當作底層框架，雖然盡量使用裏頭整合好的jquery套件，這篇就假設預設框架未提供datepicker相關套件，跟著筆者一起來看看怎麼跟ChatGPT互動寫出datepicker的效果吧。

前情提要

平常寫的Restful API的測試工具有百百種，筆者這邊所說的測試並非QA寫的那種測試，而是確認自己寫好的API是否如期執行，確認運作狀況，畢竟Restful API大多使用在前後端分離的開發方式中，身為後端工程師，寫完API，第一件事是打開Postman工具，輸入API Url，發出Request，看是否正常運行，更甚者，會製作Postman Collection並匯出給前端工程師使用，回到gRPC服務，是否也可以透過Postman來測試呢，跟著筆者一起看下去吧。

前情提要

筆者於[DotnetCore]gRPC101: Gretting專案-Server篇中詳細交代產生該系列文之原因了，因篇幅太長，決定分為Server篇及Client篇，簡述一下Client端的作法，還記得Server篇中提到以及宣告好的proto檔案嗎，對於Client端來說，只要拿Server端產生的proto檔案拿來用即可，因為也是要產生編譯後的cs檔案，namespace要改成Client端專案名稱即可，一切就水到渠成了，接下來就拿proto檔中的方法呼叫下去就萬事ok了，跟著筆者看下去吧。

前情提要

筆者因公司內部系統規劃，會有一個中台系統，負責共用的一些寄電子信件，寄簡訊，或其他共用服務，這種微服務概念而個別建立的系統，與其他系統最直觀的串接方式為Restful API， 當然還有一個GraphQL這個選擇，其特色為由前端決定回傳的資料結構，但筆者熟悉的dotnet生態圈一直沒有紅起來的感覺(或許是筆者見識淺薄)，gRPC尚未出現前，這兩種都是上等之選，gRPC問世後，有一種橫空出世的感覺，因尚未支援瀏覽器端，以微服務(後端)之間串接來說，已經是一時之選。

前情提要

筆者收到主管的指示，要來寫一個執行檔(exe)程式，筆者離這種exe程式好久遠了，自從轉換到Web領域後幾乎都是寫API為主，一開始從.net MVC5開始進入Web領域，寫了幾年的Razor View後，前一份工作剛好前後端分離，前幾年都在寫dotnet core web api及angular為主，Console Application離我好遙遠阿，但筆者已經被dotnet core的內建DI機制及AppSettings當Config已經習以為常，對於Console Application來說這些都是要自己實作上去的，不妨藉由這次機會來實作看看。