0%

前情提要

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

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

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

閱讀全文 »

前情提要

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

閱讀全文 »

前情提要

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

閱讀全文 »

前情提要

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

閱讀全文 »

前情提要

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

閱讀全文 »

前情提要

筆者在公司負責的專案,大多數都跟其他廠商串接有關,串接方式百百種,最多就是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檔案,多種形式見怪不怪,串接這時候釐清問題是最重要的,因此必須要確保我方系統上保有RequestResponse以釐清問題,也是自保的一種概念,因為你無法保證串接的Method跟金額無關,這時候唯有留下系統軌跡才能保證你的清白(被害妄想症上身中),筆者相信留下紀錄這件事,不管事不是跟別的系統串接,仍是很重要的課題。

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

閱讀全文 »