如果你經常去查閱相關的互聯網協議，比如：HTTP，MetaWeblog API，ATOM，WebDav，SMTP。你都會不經意的發現它們都有一個相對的RFC編號，這些編號會對應一個像“http://tools.ietf.org/html/rfc2616”的一個鏈接頁面，這個頁面詳細說明了該協議的定義規范。通常一個協議都定義都需要比較長的內容，但是通過閱讀這些協議本身我們就可以更好，更完全的理解該協議本質和實現方法，這將更有助于我們去實現協議基礎上的應用。這組RFC編號具有如此重要的意義，我們也就有必要更多的去了解RFC。

　　RFC是Request For Comments縮寫，它實際上是一個“備忘錄”的作用，是由IETF進行管理和發布的一系列以編號排定的文件。這些文件描述了Internet相關協議的研究，行為意圖，實現方法。現行基本的互聯網協議都在RFC文件內有詳細的說明，比如Http 1.1協議對應的的RFC2616。同時RFC也是在不斷的豐富和完善中發展，任何人都可以提交自己最新的研究成果成為RFC的一部分，比如ATOM，盡管目前還沒有成為業界標準主流，它目前還沒有辦法完全取代RSS 2.0在人們心中的影響，但是它也已經有了自己的RFC編號rfc5023。作為一個開放的發展標準，已經成為IETF的建議標準，用于取代相對封閉，存在多種非標準形式的應用的RSS規范。RFC也是一個管理嚴格的規范，任何標準，一旦被審定發布，就不允許進行修改。而一旦需要進行修改就必須重新發布一個新的編號，并且聲明作廢或更新哪些舊的規范編號。這樣保證了任何人在任何時候查看到的規范編號內容都是唯一的，不容易產生歧義。比如RFC2616的發布，就聲明作廢了原有的rfc2068編號，但是它們的協議名稱沒有發生任何的變化。

　　可以說，任何與互聯網相關的協議標準被包含在RFC里面，不僅是HTTP協議之類的應用層協議，還包括處理相對底層的IP, TCP等網絡傳輸層標準。RFC涵蓋了這么多協議規范，那么我們是不是應該通讀了解所有的這些協議規范？處于應用層開發的我們，我認為不需要完全深入的去了解這些協議的所有細節，在具備一定的網絡體系結構知識基礎之上，我們只需要關注我們工作重點涉及到的協議。那么，我們開發Web應用的程序員，需要了解哪些RFC規范呢？

1. HTTP 1.1，對應RFC編號以上已經多次提到：RFC2616。這是現代互聯網應用的一個基礎傳輸協議，協議定義了客戶端如何獲取Web服務器資源，需要發送哪些頭信息，如何向服務器提供數據，服務器如何返回用戶需要的信息等等請求過程。它有一系列基本的請求謂詞定義，比如我們常見會有GET，POST。它有一系列的請求響應代碼，比如我們經常碰見的有：200(OK), 404(NOT Found), 301和302重定向等等，還有很多很多的內容。這些內容，現在都已不僅僅是停留于理論之上，都是我們每天工作中會使用和接觸到的東西。如果你現在對這些概念都還模棱兩可，甚至于從未見過，那只能說你深受ASP.NET WebForm之害了。雖然我已有兩年的時間沒有進行于WebForm的開發，但是我還對WebForm的體系結構還算了解。現在我面試求職者的時候，WebForm的體系結構也是我的保留題目，因為我知道現在大部分的ASP.NET開發都還是基于WebForm之上。但是我卻發現大部分開發人員都還不是特別清楚WebForm的整個體系結構和事件處理流程。他們每天工作的內容就是使用控件，定義控件Postback事件，然后完成一個功能，就這樣一個功能接著一個功能，工作2，3，甚至5年以上都還是那一套工作模板，代碼生成，以不變應萬變。我認為以不變應萬變沒有什么不對的，但是不變的對象是我們開發人員必須搞清楚了。我們說，基礎是不會變的，協議也不是天天變的。當你深入對了解WebForm體系結構的時候，你也就會了解的利害之處，也就懂得了在目前還無法改的情況下如何去更好的利用WebForm。而當你了解了WebForm之后，你會發現，它之后還有更為基礎的東西，那就是HTTP協議。請求一個頁面，發送了什么請求；進行Postback時，進行了什么操作；HTTP是一個無狀態的協議，我們又是如何能直接通常服務器控件的實例來取得它的值，如SelectedValue。所以作為ASP.NET程序員的我們，要深入Web開發，第一步就是要突破WebForm，完全掌握WebForm原理，這樣不管你是還會選擇WebForm，還是轉而使用ASP.NET MVC，都不是最重要的。因為你掌握了HTTP基本原理，了解了Web的本質，你也就可以做到以不變應成變了。

2. HTML，對應的最新RFC編號：RFC 2854。HTML是每一個Web開發人員都必須了解的標記語言，它是Web UI的基礎語言，與Javascript、CSS等語言組成現代Web客戶端開發的三大利器。Web前端開發是一個獨立的崗位分類，一個好的.NET程序員并不一定是好的Web前端開發人員，但是他一定是會了解前端開發技術的程序員，這就包括了解HTML、Javascript和CSS。我們并不需要成為HTMl的專家，但我們要知道我們開發Web程序，并不是簡單的拖拉WebForm Server控件就可以完成的。進而我們也會了解什么是XHTML，以及為什么我們現在創建的每一個.aspx頁面默認在最開頭都有這樣一行代碼：http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd。

　　以上兩個RFC規范都是用W3C組織制定的，也是構成Web應用的兩個基本規范，也是個人認為作為Web程序員必須要了解兩個協議規范，也歡迎各位讀者補充。

　　除了了解一些基礎RFC標準之外，當我們的應用程序要提供某種功能的開放API的時候，我們也應該盡量遵從某種現有的規范標準。遵從標準可以簡化我們的開發，因為每一種標準基本上都有基本各個平臺的實現。同時也更有利我們推廣這些API，用戶可以使用現有的標準工具來使用我們的API。互聯網應用越來越走向開放，開放API已經成為一程序不可逆轉的趨勢。當我們的應用越來越成熟和廣泛之后，我們也完全可以根據自己的應用提出一些標準。以下是Kooboo CMS目前所使用的一些開放API的標準，有的可能還不是RFC標準。

1. Metaweblog API，基于XML-RPC之上的博客日志發表協議。XML-RPC是一個XML遠程調用的基礎協議，基于該協議之上可以有很多的應用被實現，不過我不解的是為何XML-RPC和基于它之上的應用協議都沒有被提交到RFC“備忘”，可能是因為類似的功能在RFC里已經有了一個ATOM，但是在Metaweblog API這個頁面的標題卻是以RFC開頭，我也不清楚這里的RFC是什么概念。不過即使是這樣，也不影響我們對這個API的使用，因為目前大部分的博客客戶端都支持該協議。在Kooboo CMS中，我們使用該協議來發布Kooboo CMS的內容。用戶定義的任何的文本內容都可以通過該協議來發布。這里有Metaweblog API的.NET實現。

2. WebDav，對應的RFC編號：RFC4918。WebDAV協議是基于HTTP協議基礎之上，用于定義服務器文件操作服務接口。關于WebDAV協議的應用，在WebDav 在Kooboo CMS中的運用這篇博客中已經介紹過。

3. RSS，如上介紹雖然不是RFC標準，并且已經有了相應的替代協議ATOM，但是目前仍然是一種主流的內容訂閱標準。在Kooboo CMS中，提供了一個種簡單的方式來開發RSS內容訂閱服務。

　　標準可以統一和簡化我們溝通和交流的方式，降低生活和生產成本。在Web開發中，了解RFC應該是我們行業技能的另一外標準。