请求大小VS服务器负载
我写的关于如何组织是在一个HTTP请求发送的查询参数的规范，我想出了以下内容：请求大小VS服务器负载
所有参数与实体前缀，以他们属于一个例子“ab”，它被读作“实体a的b”，这样每个参数将被清楚地映射到相应的实体，但是如果存在共享查询参数的两个不同实体呢？以避免重复和请求大小我想出了以下微格式。要有一个名为shared的请求范围实体，shared的每个属性将表示在实体间共享的属性，例如，
POST /app/my/resource HTTP/1.1
a.p = v
b.p = v
c.p = v
d.p = v
这清楚地表明财产p是其中a,b,c共享和d所以这可能是因为
POST /app/my/resource HTTP/1.1
shared.p = a:b:c:d%v
现在发送，请求比较小，我是有点更DRY，但是这给服务器增加了额外的负担，因为它必须解析字符串才能处理这些值。
也许在我的例子中，差异是微不足道的，我可以选择，但我想知道你对它有什么看法，你喜欢什么，也许请求的大小无关紧要，或者可能是当长度很短时，解析字符串并不是什么大问题，但是当我们扩大请求和字符串的大小时会发生什么，哪一个更好，什么是折衷？
你所显示的是一种压缩算法。请注意，有效载荷通常在协议层上已被压缩（HTTP，gzip Content-Type，请参阅HTTP compression examples）。压缩算法足够先进，可以压缩重复的字符串项目，所以可能你不会通过自定义压缩获得太多的收益。
一般尽量不要过早优化。首先显示您正在处理响应时间或有效负载大小问题，然后进行优化。你的压缩算法本身是一个好主意，但它使得有效载荷比普通的键/值对（xxx-form-urlencoded Content-Type）更复杂。出于维护的原因，尽可能采用最简单的设计。
只是为了抛出这个问题，我认为答案取决于您的后端服务器运行哪个平台来处理请求。例如，我最后一次检查时，基于Perl的mod_perl可以更快地解析这些字符串，比如ASP.NET。