闲话RFC，互联网营销

　　如果你经常去查阅相关的互联网协议，比如：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应该是我们行业技能的另一外标准。