我正在编写有关如何组织HTTP请求中发送的查询参数的规范，我想出了以下内容：
所有参数都以它们所属的实体为前缀，例如“ab”，读作“b of entity a”，这样每个参数都会清楚地映射到相应的实体，但如果有两个参数则会怎样共享查询参数的不同实体？，为了避免重复和请求大小我想出了以下微格式。要拥有一个名为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 :(得分：0)
只是把它扔出去，我认为答案取决于你的后端服务器运行什么平台来处理请求。例如，我上次检查时，基于Perl的mod_perl可以更快地解析这些字符串，就像ASP.NET一样。
答案 1 :(得分：0)
您展示的是压缩算法。请注意，有效负载通常已在协议层上进行压缩（HTTP，gzip Content-Type，请参阅HTTP compression examples）。压缩算法足够先进，可以压缩重复的字符串项，因此您可能无法通过自定义压缩获得太多收益。
一般尽量不要过早优化。首先表明您有响应时间或有效负载大小问题，然后进行优化。您的压缩算法本身是一个好主意，但它使有效负载更复杂，因为正常的键/值对（xxx-form-urlencoded Content-Type）。出于维护原因，可以选择最简单的设计。