公共(public) Web 服务通过 URL 接受配置选项。每个请求将使用 200 个可用选项中的大约 20 个,每个选项都是一个 true
或 false
值。该服务是无状态的,响应将被缓存。
到目前为止的典型示例:
http://api.milk.shake/?likesVanilla&likesChocolate=true&likesStrawberry=true
除非指定,否则假设每个值为 false,因此缩短为:
http://api.milk.shake/?likesVanilla&likesChocolate&likesStrawberry
对于 20 个选项,生成的 URL 仍然很长且笨拙。我怎样才能使它们更短、更整洁,并使它们在野外有效和可用?
在下面的示例中,假设 URL 重写将 URI 转换为查询参数
方法 1 - 为每个选项分配一个字符
例如A = likesVanilla
,B = likesChocolate
,C = likesStrawberry
典型调用是http://api.milk.shake/ABC
失败因为URLs can use A-Z、a-z、0-9 和 $-_.+!*'(),
仅涵盖 200 个可用选项中的 73 个。
方法 2 - 二进制表示
例如 1 = likesVanilla
,2 = likesChocolate
,4 = likesStrawberry
典型的调用是http://api.milk.shake/7
(可能是十进制或十六进制)
其中 7 = 1 + 2 + 4 = Vanilla + 巧克力 + 草莓
失败,因为指数是指数 - 第 63 个选项的数组索引为 4611686018427387904
,第 64 个选项会破坏 PHP,除非我测试错了..
高效,因为参数顺序是统一的,所有类似的请求都被缓存。
方法 3 - 用 1 或 2 分组
我可以在 URL 中定义选项组。这限制了每个组中可用选项的数量,并允许使用方法 1 或方法 2。
例如:
第 1 组选项 A = likesVanilla
,B = likesChocolate
,C = likesStrawberry
第 2 组选项 A = likesCream
,B = likesSprinkles
典型调用是http://api.milk.shake/ABC/AB
(第一组/
第二组等)
到目前为止,这是我首选的方法。可能是在回答我自己的问题!
方法 4 - 转义字符
如果字符是escaped correctly然后大约 220 个字符可用。
典型的调用是http://api.milk.shake/%41%42%43
最多 220 个选项不是面向 future 的,但可以与方法 3 一起使用。看起来不整洁。
最佳答案
如果您将选项分成较小的集合,例如 4 组,每组 50 位,则选项 2 可能有效。
刚刚意识到您已经说了与选项 3 一样多的内容,但还没有说到这里。但是,您可以使用 BCMath将其作为一个大整数来完成。
关于php - 在 URL 查询中表示约 200 个 bool 标志,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/35895409/