2011-09-24 160 views
0

我写的关于如何组织是在一个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,但是这给服务器增加了额外的负担,因为它必须解析字符串才能处理这些值。

也许在我的例子中,差异是微不足道的,我可以选择,但我想知道你对它有什么看法,你喜欢什么,也许请求的大小无关紧要,或者可能是当长度很短时,解析字符串并不是什么大问题,但是当我们扩大请求和字符串的大小时会发生什么,哪一个更好,什么是折衷?

回答

0

你所显示的是一种压缩算法。请注意,有效载荷通常在协议层上已被压缩(HTTP,gzip Content-Type,请参阅HTTP compression examples)。压缩算法足够先进,可以压缩重复的字符串项目,所以可能你不会通过自定义压缩获得太多的收益。

一般尽量不要过早优化。首先显示您正在处理响应时间或有效负载大小问题,然后进行优化。你的压缩算法本身是一个好主意,但它使得有效载荷比普通的键/值对(xxx-form-urlencoded Content-Type)更复杂。出于维护的原因,尽可能采用最简单的设计。

0

只是为了抛出这个问题,我认为答案取决于您的后端服务器运行哪个平台来处理请求。例如,我最后一次检查时,基于Perl的mod_perl可以更快地解析这些字符串,比如ASP.NET。