基于WCF的RESTFul WebAPI如何对传输内容实现压缩
前言
WCF作为通迅框架可以很容易地实现对消息的压缩，且方法不止一种，主要解决方法主要有以下四种：
1、通过自定义MessageEncoder和MessageEncodingBindingElement 来完成。具体的实现，可以参阅张玉彬的文章《WCF进阶:将编码后的字节流压缩传输》；
2、直接创建用于压缩和解压缩的信道，在CodePlex中具有这么一个WCF Extensions；
3、自定义MessageFormatter实现序列化后的压缩和反序列化前的解压，详见WCF大师Artech中的博客有《通过WCF扩展实现消息压缩》；
4、自定义MessageInspector实现，详见博客园似若流云的文章《WCF 消息压缩性能问题及解决方法》。
这几种方法实现、配置都很简单。后两种方法的内部实现方法很类似，区别在于第三种方法通过自定义MessageFormatter中对消息进行压缩和解压缩，而第四种方法是在自定义MessageInspector中对消息进行压缩和解压缩。比较而言最后一种是最简单粗暴的。
几种方案的适用场景
那么，这几种方法都适用于什么场景呢？从技术上看，这4种方案基本可以分为两类。一种是在消息编码器上动手脚，另一种是在消息上做文章。
第一种是属于在消息编码器上动手脚的，实现稍复杂。应用场景比较广泛，基本上所有的场景都是适用的。
后面三种都是在消息上做文章的，只适合有WCF客户端的情况，因为如果没有客户端压缩时在消息中加入的压缩标志，服务端就没法正确解压，反之亦然。虽然原理相同，但三种方法的切入点各不相同。同时，第二种方法是可以改成在消息编码器上进行压缩/解压的。
因为RESTFul的WCF的客户端不仅仅是WCF，所以暂时只能选第一种方案了。
一个问题
虽然有现成的方案可用，但是，如果要完美支持多种客户端的话，这里面还有几个问题需要解决。
按照Http协议的规范，客户端发送/服务端返回一个压缩的数据，需要在协议头部加上Content-Encoding，并设置其值为gzip或者deflate。告诉对方数据的压缩方法，好让对方能够正确解压。
如果客户端希望返回的数据是压缩的，那么就在头部加上Accept-Encoding，并设置其值为gzip或者deflate服务器收到这个信息后，就知道客户端选择的压缩方法，就可以按照客户端指定的方法去压缩数据。
然而，无论哪种方案，都是需要事先配置压缩方式的。也就是说，需要双方事前约定，无法实现用Content-Encoding的值来告知对方压缩方式！这不优雅！！在很多时候，这是个大问题！！！
解决的办法
我们知道，第四种方案的切入点在消息检查器上，在这个点上，通常会实现一些自定义的拦截功能。一个自定义的消息检查器需要继承IDispatchMessageInspector，这个接口类定义了两个接口：
object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
void BeforeSendReply(ref Message reply, object correlationState)
AfterReceiveRequest作用在收到消息后，BeforeSendReply作用在发送响应消息前。
我们可以通过下面的代码，来根据请求头的Accept-Encoding的值，给消息加上对应的压缩标示，以便消息编码器选择正确的压缩方式；并在返回响应前在响应头部加上Content-Encoding并设置相应的值，以便客户端正确解压。
using System.Linq;
using System.Net;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.ServiceModel.Dispatcher;
namespace Insight.WCF.CustomEncoder
{
public class CompressInspector : IDispatchMessageInspector
{
public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
{
var property = request.Properties[HttpRequestMessageProperty.Name] as HttpRequestMessageProperty;
var accept = property?.Headers[HttpRequestHeader.AcceptEncoding];
switch (accept)
{
case "gzip":
OperationContext.Current.Extensions.Add(new GzipExtension());
break;
case "deflate":
OperationContext.Current.Extensions.Add(new DeflateExtension());
break;
}
return null;
}
public void BeforeSendReply(ref Message reply, object correlationState)
{
var property = reply.Properties[HttpResponseMessageProperty.Name] as HttpResponseMessageProperty;
var exts = OperationContext.Current.Extensions;
if (exts.OfType(GzipExtension).Any())
{
property?.Headers.Add(HttpResponseHeader.ContentEncoding, "gzip");
}
else if (exts.OfType(DeflateExtension).Any())
{
property?.Headers.Add(HttpResponseHeader.ContentEncoding, "deflate");
}
}
}
public class GzipExtension : IExtension
{
public void Attach(OperationContext owner)
{
}
public void Detach(OperationContext owner)
{
}
}
public class DeflateExtension : IExtension
{
public void Attach(OperationContext owner)
{
}
public void Detach(OperationContext owner)
{
}
}
}
未彻底解决的问题
因为消息检查器的AfterReceiveRequest作用在收到消息后，也就是说，对于POST/PUT/DELETE这三类请求，它们如果对提交的数据进行了压缩的话，我们无法在消息编码器中根据Content-Encoding的值进行解压。消息编码器中的ReadMessage方法是这样的：
public override Message ReadMessage(Stream stream, int maxSizeOfHeaders, string contentType)
所以，如果要实现由客户端来决定POST/PUT/DELETE数据的压缩方式的话，只有在Content-Type上面搞点小动作。
这。。。。。。
不够优雅呀！
看来得研究下改造第二种解决方案了。生命不止，折腾不息
源代码在这里：https://github.com/xuanbg/Utility/tree/master/CustomEncoder
