[DotnetCore]Refit:API介紹及應用
[DotnetCore]Refit:DotnetCore專案套用
前情提要
筆者在上一篇: [DotnetCore]Refit初體驗 ,簡單介紹Refit的使用方式,因上篇中要簡單的呈現,因而透過Linqpad
來完成示範,這篇則建立Dotnet Core
完整專案,並將Refit
套上使用。
[DotnetCore]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)
,不查還好,查完後覺得就它了。
[DotnetCore]AOP初體驗
前情提要
筆者負責的專案,是那種到處要跟第三方串接那種,第三方不管是內部或多個外部,串接方式不外乎就是WebService
或是Restful API
,或者提供dll
檔案,多種形式見怪不怪,串接這時候釐清問題是最重要的,因此必須要確保我方系統上保有Request
及Response
以釐清問題,也是自保的一種概念,因為你無法保證串接的Method
跟金額無關,這時候唯有留下系統軌跡才能保證你的清白(被害妄想症上身中),筆者相信留下紀錄這件事,不管事不是跟別的系統串接,仍是很重要的課題。
然而對於Restful API
這種串接方式,最方便留下紀錄了,只要共用一個HttpClientRepository
,將發出HttpRequest
集中在某一個Method
中,方便事後增加其往來紀錄的相關程式碼,當然我方系統是被呼叫方的話,也是可以透過DotnetCore
內建的Middleware
能搞定。至於呼叫WebService
或者dll
檔案中的Method
則比較傷腦筋一點,動用到今天的主角,AOP Logging
,能夠輕鬆地不留痕跡地做到留下紀錄。
[雜記]ChatGPT初體驗
[DotnetCore]gRPC101:Postman發出gRPC Request
[DotnetCore]gRPC101: Greeting專案:Client篇
前情提要
筆者於[DotnetCore]gRPC101: Gretting專案-Server篇中詳細交代產生該系列文之原因了,因篇幅太長,決定分為Server篇及Client篇,簡述一下Client端的作法,還記得Server篇中提到以及宣告好的proto
檔案嗎,對於Client
端來說,只要拿Server
端產生的proto
檔案拿來用即可,因為也是要產生編譯後的cs檔案,namespace
要改成Client
端專案名稱即可,一切就水到渠成了,接下來就拿proto
檔中的方法呼叫下去就萬事ok了,跟著筆者看下去吧。