其他

　　我們知道，在HTTP協議的報文頭Header中存放著許多資訊。如果你讀過老A的《通過添加HTTP Header實現上下文資料在WCF的自動傳遞》，那你一定知道如何通過底層的擴充來實現如何在REST WCF中使用HTTP Header來進行資料互動。這對於大家更多的瞭解WCF的底層機制有很大的協助作用。　　竊以為：在實際的REST

　　前幾節介紹了REST WCF 服務的一些基本的特點，本節說明一下，如何基於HTTP的標準動作來使用REST WCF 服務。由於RESTful服務的架構風格基於HTTP協議，並且其設計原則中明確指出:通過通用的連接器介面來使用資源。對於REST架構風格的服務，主要通過它8個動作中的4個來使用資源，即:GET,POST,PUT,DELETE。　　在RESTful

　　作為一種以HTTP協議為基礎的WCF

　　Fiddler是一款強大的軟體，在實際的開發中它能協助我們跟蹤HTTP請求，記錄發送請求和擷取到請求結果的資料。使用VS2008的時候，一直是用IE6瀏覽調試，使用Fiddler也正常。但本人一直習慣用FireFox，可憐用它訪問的時Fiddler卻不能協助記錄下資料（FireFox版本：4.0）。還以為Fiddle只能在IE下使用，試了試chrome，發現也可以用。言歸正卷,本篇針對上篇中的REST服務（具體例子以及帶代碼採用上節中介紹的：通過HTTP協議標準動作使用REST WCF

　　近來看了Jim

在定義API的時候，對於一些返回集合對象的方法，很多人喜歡將傳回型別定義成IEnumerable<T>，這本沒有什麼問題。這裡要說的是另一個問題：對於傳回型別為IEnumerable<T>的方法來說，我們可以使用yield return的方式來輸出返回集合的元素。但是如果我們不瞭解yield

　　.Net SDK下有很多命令工具，有許多在我們平時開發應用中很有協助。最近看書總結了一些，但是難免有點以偏概全，掛一漏萬。下面就介紹這些命令的基本用法，實際應用中可以參考MSDN。　　切入正題，開啟SDK命令提示，如：1、ildasm (IL Disassembler IL

　　這幾天思考REST 架構下POST複雜資料類型的問題查了寫資料，以及通過與WCF 大牛------Frank Xulei進行了一番交流對REST有了一些進一步的認識。本篇作為：1、REST與SOA兩種架構下WCF的異同比較 　　2、通過HTTP協議標準動作使用REST WCF

　　網上有許多介紹REST的資料，在這大部分資料中，基本都會介紹通過URI隧道技術與通用的連接器介面（也就是POST\GET\PUT\DELETE，即CRUD）對資源進行操作。　　那麼支援URI隧道技術與CRUD的服務就表明我們的服務就是REST風格的了嗎。？事實上在Richardson成熟度等級模型中，URI隧道技術與HTTP出於第一級與第二級。如：　　在他的最上層就是本節所敘述的超媒體（HyperMedia）。　　本節目錄：1、超媒體格式2、超媒體格式與POX比較3、如何處理超媒體4、標準超

　　.Net Remoting是微軟早前推出的一項分布式通訊技術架構，在.Net架構的程式中有著比較廣泛的應用。在WCF中，已經整合了Remoting的技術。不過，他們有著很多相同的概念，如：通道(Channel)、代理（Proxy）、寄宿（host）等。在如今仍有一些分布式系統應用中運行著由Remoting技術構建的系統。本文將描述在服務端與用戶端的互動中，他們各自的實現方式。　　1、Remoting的實現。                                          

　　前面一節中講述了REST架構風格中最核心本的要素之一：超媒體格式。雖然超媒體格式有很有用，如能被瀏覽器很好解析的HTML。但是HTML也不是萬能的。如我們在AJAX應用中，使用JSON表述格式很顯然比HTML要好。再者，我們為了實現某一特定領域而採用自訂的超媒體格式，如果消費者只需要處理表述中的一小部分，雖然我們可以通過擷取資源的表述，然後過濾出我們需要處理的資源，但這顯然不是一種好的方式。Atom社區所制定了一條深受歡迎的慣例。目錄：　　1、Atom簡介　　2、Atom1.0與RSS2.0

　　Remoting技術推出好多年了，一直沒有系統的去瞭解它，之前粗略看了點資料後來也中斷了。現在重新開始學習這一技術並記錄下學習的過程。　　也許有人說現在不是有了WCF嗎。?Remoting不是整合到WCF中了嗎？為什麼還要學習它呢？首先:為不否認現在有了更好整合了Remoting、MSMQ、WEB SERVICE這些優秀技術的WCF，但是我想既然是整合，那WCF一定集中了上述技術的優點，並且WCF應該是在Remoting、MSMQ、WEB

昨天寫了《yield在WCF中的錯誤使用——99%的開發人員都有可能犯的錯誤[上篇]》，引起了一些討論。關於yield關鍵字這個文法糖背後的原理（C#編譯器將它翻譯成什麼）其實挺簡單，雖然有時候因為誤用它會導致一些問題，但是它本無過錯。接下來，我們通過這篇短文簡單地談談我所理解的yield。目錄 一、先看一個簡單的例子 二、瞭解本質，只需要看看yield最終編譯成什麼

　　前面幾節介紹了REST WCF

　　REST（Representational State Transfer）與SOA（Service-Oriented

　　前一節介紹了一種IETF推薦的一種超媒體格式------Atom，這一節中主要Atom發布協議-------Atom Publish Protocol,簡稱AtomPub,有時更簡潔寫作APP。　　開篇之前介紹幾個重要概念先：　　1、媒體類型　　描述相關資源表述所使用的類型，如XML、JSON、JPG、MP3等、處理模型以及連結關係值　　2、HTTP慣用語　　它規範了如何對資源進行操作以及處理HTTP頭資訊和狀態代碼　　3、領域應用協議。　　領域應用協議(Domain

Jquery作為一款優秀的JS架構，簡單易用的特性就不必說了。在實際的開發過程中，使用JQ的AJAX函數調用WebService的介面實現AJAX的功能也成了一種比較普遍的技術手段了。WebService介面的實現，通常都是由OOP語言實現的。所以在WebService的介面函數中，難免可能會遇到除了單一資料型別的複雜資料類型。複雜的資料的資料類型機有可能是WebService介面中的參數，也有可能是WebService的傳回值。本文所敘述的要點為：1、對於WebService介面複雜類型的參數

在HTTP1.1規範中，新增了一個HTTP頭資訊：ETag。對Web開發人員來說，它是一個非常重要的資訊。它是用作緩衝使用的兩個主要的頭資訊之一 (另一個是Expires)。除此之外，在REST架構中，它還可以用於控制並行作業(上節中已經大致介紹AtomPub中控制並發的流程)。那麼ETag是什嗎？它又幾種類型？強ETag與弱ETag之間有什麼區別。？如何計算ETag值?它與Last-Modified頭資訊在使用上有什麼區別？本節主要圍繞這幾個方面敘述一下自己的理解。目錄：什麼是ETag？

      上節介紹了REST WCF 4.0相比3.5支援更多的互動格式，本篇就說說在Server與Client間通過最原始的流的格式進行通訊。開篇之前，介紹REST WCF 的一個特性：DescriptionAttribute。對這個特性相信都很熟悉，它的作用如同在WebService中通過它來標註出某個介面的描述資訊，在REST WCF中同樣如此。將它標註在REST WCF 介面中後，在help頁面中將會顯示介面的描述資訊。　　如以往，本篇將通過Demo的形式介紹如何在REST

文章目錄   緩衝通道(cache channel) 回顧一下在REST WCF 4.0中可以這樣簡單實現緩衝：1、配置 <caching>    <outputCacheSettings>        <outputCacheProfiles>            <add duration="20" name="outCache" varyByParam="none"/>