V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
httpbin - 协议调试工具
httpstatuses - 协议状态码查询
httpie - cURL-like tool for humans
Fiddler
mytharcher
V2EX  ›  HTTP

设想了一种 HTTP 更丰富语义查询参数的格式,不知道是否已有类似的标准或者方法?

  •  1
     
  •   mytharcher · 2019-11-21 16:37:55 +08:00 · 2735 次点击
    这是一个创建于 1839 天前的主题,其中的信息可能已经有所发展或是发生改变。

    在 RESTful 的查询设计中,通过 URL query 传递查询参数大部分只能使用 a=1&b=2 这样的形式,一些情况下总感觉不够用,尤其是在范围查询的时候,很难表达条件是大于一个数且小于一个数的情况。

    所以考虑通过一些符号增加查询参数的表达,归纳了一些想法如下:

    查询规则

    可用数值比较的情况:

    • date=2019-01-01:相等查询
    • date=[2019-01-01,2019-01-31]:范围查询
    • date=[2019-01-01,2019-02-01):闭开区间
    • date=[2019-01-01,2019-01-31]|[2019-03-01,2019-03-31]:多区间查询
    • date=[,2019-01-31]|[2019-03-31,]:半区间查询

    其中 | 连接同一个参数的“或”(OR)条件,()[] 表达开闭区间。

    同时也想到针对字符串匹配的情况:

    • name=keyword:精确匹配
    • name=keyword*:开头匹配
    • name=*keyword:结尾匹配

    集合查询:

    • id={1,2}IN 表达

    反转条件:

    • date=![2019-01-01,2019-02-01):不在 2019 年 1 月内的日期
    • name=!keyword:不相等
    • id=!{1,2}NOT IN 表达

    缺陷或问题

    1. “且”(AND)条件暂时还没想好如何表达,也许可以用 ^ 符号代替?
    2. 小括号因为用于开区间,没有用于表达运算优先级的符号了,或许用尖括号 <> 代替?或者因为情况太少可以放弃。
    3. 为什么不用 GraphQL ?不是一个方向,GraphQL 更侧重于级联组合查询和属性筛选。

    目前也只是个非常初步的想法,不知道各位在实践中有没有更好的方法?

    14 条回复    2019-11-22 15:16:03 +08:00
    xream
        1
    xream  
       2019-11-21 16:52:10 +08:00   ❤️ 1
    shoaly
        2
    shoaly  
       2019-11-21 16:52:50 +08:00
    多余的设计, 不应该是 http 那个层级想得事情, 属于项目或者团队内部定一个就好
    Vegetable
        3
    Vegetable  
       2019-11-21 17:03:14 +08:00
    这个本身和 http 关系不大吧
    完全看团队怎么定义

    date 区间一般都是 start end 这样去,何必非得一个参数搞定呢.和你的思路比较像的大概是 mongodb 的查询语法.
    {key:{$gte:1,$lte:2}}
    django 的 orm 是(key__gte=1,key__lte=2)

    感觉上你是不满足于 http 中只有等号,希望表示更复杂的运算关系,据我所知没有一套这样的约定,也许你更需要的是 graphQL 之类
    fancy111
        4
    fancy111  
       2019-11-21 17:09:33 +08:00
    多此一举,数据传到后台随便你怎么组合,为什么要 HTTP 来传组合?
    你传 A,B 两参数,后台可以变成 A*B,A+B,A-B,A/B,A.B.....随便你组合,但是你如果传你那种固定格式,就是写死了而已。
    sagaxu
        5
    sagaxu  
       2019-11-21 17:29:47 +08:00 via Android   ❤️ 1
    等一个人
    009694
        6
    009694  
       2019-11-21 17:34:10 +08:00   ❤️ 1
    第一反应是 Apache Lucene - Query Parser Syntax
    mytharcher
        7
    mytharcher  
    OP
       2019-11-21 17:38:14 +08:00
    @xream
    看了一下表达上(或者说参数名)设计的不是很直观,结构也多了一层,不是特别希望按这样的方式。不过非常感谢给出参考以启发思路!
    mytharcher
        8
    mytharcher  
    OP
       2019-11-21 17:42:05 +08:00
    @Vegetable
    是的,不满足于只有等号的表达,不想用 `start`/`end` 主要是这个参数名不是直接映射到字段名。的确也只是先在团队内尝试,所以希望能找出一个比较好的约定方式。
    mytharcher
        9
    mytharcher  
    OP
       2019-11-21 17:46:32 +08:00
    @shoaly
    @fancy111
    可能我没表达好,没有希望把这种“约定”上升到 HTTP 的标准,只是希望利用 HTTP 已有的格式做一些渐进性的增强。如果能形成一套规则体系,那么后台处理的时候也会是一个形式化的“处理机”,不需要每个接口开发人员自己约定一套自己的映射方式,更有利于团队统一。
    imdong
        10
    imdong  
       2019-11-21 17:47:50 +08:00
    直接传 SQL 为什么不行呢?
    fangzy
        11
    fangzy  
       2019-11-21 18:02:02 +08:00 via Android   ❤️ 1
    楼主这个需求有 rsql 和 fiql 比较接近
    molvqingtai
        12
    molvqingtai  
       2019-11-22 01:43:14 +08:00 via Android
    那个男人好久没来了
    mytharcher
        13
    mytharcher  
    OP
       2019-11-22 10:35:27 +08:00
    @imdong
    直接传 SQL 的问题是后端做安全性防御的时候解析起来要比一些简单格式麻烦的多,而且 SQL 灵活性太大。而设计一个简单格式可以满足大部分查询需求的话其实也就是一种折中。
    TommyStandard
        14
    TommyStandard  
       2019-11-22 15:16:03 +08:00
    有想法,再深入做下去就是另一个版本的 APIJSON 了
    https://github.com/TommyLemon/APIJSON
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1184 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 18:40 · PVG 02:40 · LAX 10:40 · JFK 13:40
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.