mrkt的程式學習筆記

經過兩篇文章的鋪陳，總算來到了最後一篇，將會把修改過的最後完成版提供給各位，讓各位開發 Web API 專案時在操作使用 Postman 能夠方便與易於管理。

ASP.NET Web API - Import a Postman Collection Part.1
ASP.NET Web API - Import a Postman Collection Part.2

接續上一篇的內容，來看看最原始的做法有些什麼樣的問題，先開門見山做個說明，這一篇會再沿用別人所提供的改良做法，不過最後的結果依舊還是會有一些問題存在，所以最後在第三篇的文章裡將會提供我所修改過的程式碼，而這也是我開發的專案以及部門其他開發團隊所使用的方法。

在開發過程中，開發人員主要還是會透過 Postman 進行開發的偵錯、測試、操作等，如果開發人員只有一個人的時候，在 Postman 裡增加或管理 Collection, API 都還算是可以控制，但如果是多人開發團隊共同開發一個 Web API 專案時，就會發現到每個人所使用的 API Collection 內容都有很大的出入與差異，所以就必須要有一個能夠一致化 API Collection 的功能，讓團隊的每個開發人員都使用一樣的 API Collection 進行操作。

關於 Visual Studio 佈景主題的相關文章寫了不少篇，不過都是以 Visual Studio 2013 為主，但是到了 Visual Studio 2015 卻有點不同了，例如 Studio Styles 這個提供了很多編輯器樣式的網站，絕大部分的 Style Setting 雖然依然可以在 VS2015 裡面使用，但因為 VS2015 修改了很多樣式設定的名稱，所以就會有很多地方是相當怪異，最後我就只好使用 VS2015 所提供的預設 Dark 主題，這個主題的編輯器顏色配置算是相當舒服，與 VS2013 or VS2012 原本的 Dark 主題可以感受到明顯的差別，但是看久了之後還是很不習慣，所以血液裡的搞怪因子又讓我起了動手腳的念頭，於是參考了網路上的幾篇文章與說明做了修改，最後的結果還不錯，這篇文章就為各位說明如何去動手腳。

前一篇簡單介紹如何在一個 ASP.NET Web Api 專案裡安裝 Swashbuckle - Swagger for Web Api 這個套件，基本上都沒有什麼難度，特別要注意的就是 Controller 與 Action 方法與相關類別的 XML 文件註解要記得寫以及維護，在一般的使用情況下的 Api 服務資訊提供已經相當清楚了。

不過提供更加清楚的資訊給使用 Api 服務的開發者對於產品的開發與溝通是有絕對幫助的，但老實說，要把 Swagger 寫得好又要能夠搭配 Web Api 後端程式讓資訊可以自動產生，其實也不是容易的事情，這邊就來說明幾個調整顯示資訊的做法。

Swagger 是一套 API 互動文件產生器，使用 HTML 與 Javascript 所編寫的，與之前所介紹的 ASP.NET Web API Help Page 不同的是，Swagger 是一套 Open Source Software，支援了現在許多的 REST API，之所以會說這是一個互動的文件，除了顯示 API 輸出入規格外，也能夠讓使用者即時的在 Swagger UI 介面上進行操作，立刻就能看到執行結果。

這一篇將會簡單說明如何在一個 ASP.NET Web API 專案裡加入 Swagger 功能。

這個功能的主題其實有很多人都寫過了，不過為了之後的文章，所以還是要先寫出這一篇。

大家也都知道 ASP.NET Web Api 2 都已經有內建了 Help Page 的功能，這是一個可以產生對應 API 服務的線上文件產生器，所謂的產生並不是可以幫我們做出一份 Word 或是 PDF 檔，而是指將我們所開發的 API 服務相關的輸入、輸出、Resource 等資料經由 Help Page 的功能處理並建立好網頁，在網頁上去提供了這些 API 服務的相關資訊，以方便介接 API 服務的開發人員查看。

這一篇就來簡單地介紹如何在 ASP.NET Web Api 應用服務裡啟用這一個功能。

因為這一年來主要都是在開發 ASP.NET Web Api 專案，Client 端的開發測試工具是使用「Postman」，而我也並非第一次在專案開發裡使用，在這幾年的開發裡都有使用到，只不過這次的角色從介接使用別人所開發的 Web Api 變成開發別人要使用的 Web Api，其實不管哪一種角色，使用這類的工具如何可以更加地瞭解如何應用，那麼就會省下很多很多的時間，而這一篇所要講的就是 Postman 所提供的一個功能「Generate Code Snippet」。

日前在專案執行上突然有個需求，就是要對輸入的資料做Guid格式的驗證，
一開始就下意識去找Guid下的TryParse方法，這個時候才發現 .NET 3.5(2.0) 的Guid是沒有TryParse方法…
細查下去才知道，Guid的TryParse與Parse方法在 .NET 4.0才新加入（小弟真是才疏學淺…汗顏…），
之前經常使用Guid，卻甚少對Guid的格式驗證稍加留意。

整齊、清潔、有序的程式碼對我而言是一種基本的要求，
因為在雜亂無序的程式海裡，要找尋我們的標的物真的是有如大海撈針一樣