非常贊的四篇文章：
http 常用方法：
我原先以為修改某乙個資源，也是用 post，後來發現還有乙個 patch，但發現 httpclient 並沒有提供此呼叫方法，需要我們進行擴充套件：
呼叫**：
camelcase（駱駝命名）我們都非常熟悉，因為 c# 就是使用的這個命名法，snake_case（蛇形命名）適用於 python 和 ruby，比如商品 id，camelcase 會命名為 productid，snake_case 則會命名為 product_id。
需要注意的是，snake_case 只限於 json api 命名，並不限於 uri，uri 中一般也不會使用下劃線，為什麼要對 json api 進行規範命名？因為 restful 是無狀態風格，也就是說 restful api 並不限於某一種客戶端進行呼叫，所以 json api 的命名必須要規範，如果只是 c# 呼叫的話，那麼命名採用 camelcase 命名就可以了，但顯然並不是這樣，最後得出的結論是使用 snake_case 命名會比較好，以後在設計的時候，需要注意了。
api uri 設計最重要的乙個原則：nouns (not verbs!)，名詞（而不是動詞）。
crud 簡單 uri：
上面是對某一種資源進行操作的 uri，那如果是有關聯的資源，或者稱為級聯的資源，該如何設計 uri 呢？比如某一使用者下的產品：
還有一種情況，我們一般在設計 api 的時候，會進行一些查詢操作，比如分頁和排序等，api 方法引數設計可能很容易，那重要的 uri 該如何設計呢？我們先看這樣的乙個設計：
首先，這個 uri 想要表示的意思是：獲取某一使用者下，分頁查詢的網摘列表，這個 api 設計好不好呢？我們看下 github 中的乙個 api：
"current_user_repositories_url": ""uri 表達為：獲取 space_user_id 為 1 使用者下的網摘分頁列表，上面設計會不會更好些呢？呼叫示例：
}補充：因為 space_user_id 違反 c# 的命名規則，google 搜尋「asp net web api snake_case」，卻搜多到大量的「camelcasing」關鍵字，而且在微軟大部分 webapi 示例中，route 的引數命名設計規範都是 camelcasing，所以。。。。沒辦法，只能使用 camelcasing 命名規則吧，誰讓用的是 .net 呢，不過，有人還搞了個 snakecaseformurlencodedmediatypeformatter 擴充套件，但好像是在過程中進行了轉化，並不是解決定義問題。
網摘的 api 我們再修改下：
不經意間，還發現 asp.net webapi help 乙個有意思的地方，比如上面的 api 設計，得到的是這樣的 help 說明：
如果我們把 api **修改成：
得到的卻是這樣的 help 說明：
發現有什麼不同了嗎？看來 asp.net webapi help 還是蠻智慧型的呢。
設計模式 設計原則與設計模式
一切設計都為了 的可擴充套件性和可讀性，都為了應對變化！我們是基於設計原則的思想，來選擇設計模式去實現，可讀，可擴充套件的目標！核心設計思想 對擴充套件開放，對修改關閉。含義 抽象可變功能，可變功能通過子類擴充套件實現，避免對已有抽象實現的修改。優點 便於擴充套件 核心設計思想 單個方法或單個類或單...
設計模式 設計模式
物件導向程式設計 oop 的基本概念有 封裝，抽象，繼承，多型等，如何開發出可復用的物件導向軟體一直困擾著軟體開發人員。可復用的物件導向技術包括類的繼承，物件的組合和引數化型別 generic gof的巨著 設計模式 總結出可復用的物件導向的23個設計模式，並且歸類成 建立型模式，結構型模式和行為型...
流程設計 設計框架
設計框架wfmc是國際工作流管理聯盟，它於1993年成立，發布了一系列的工作流定義 軟體介面的草案文字，是目前世界上公認的最具權威性的工作流標準制定機構，得到了廣泛的支援和應用。2002年10月25日，wfmc發布了基於xml的流程定義語言1.0版的最終 文字 workflow process de...