什么是“IS NOT SET”子句的良好API格式？

我对我的服务的查询API，它看起来像这样（JSON-ISH格式）：什么是“IS NOT SET”子句的良好API格式？

{ 
    filter: { 
      ,attribute2: [val21, val22] 
      ,attribute3: [] 
    } 
}

有效手段，选择数据WHERE attribute2 in ("val21", "val22") AND attribute3 IS NOT NULL在SQL上下的语法（意思是，被返回的对象有属性3但我真的不在乎它的价值是什么SQL当然不是很擅长表达这一点，因为我的数据是关键值存储，其中的关键字可能“没有设置”，而不是空值）。

我需要扩展这个API才能够表达IS NOT SET谓词，并且我不知道这样做的好方法是什么。

我唯一可能想到的是在请求API中添加一个特殊的“NOT_SET”值，这将产生NOT SET语义;但它似乎真的klunky和难以把握：

的API语法可以就其表现力/能力看作是JSON

一个理想的答案将参考有关API设计的一些广为接受的规则，向人们展示这很好”。

{ 
    filter: { 
      ,attribute2: [val21, val22] 
      ,attribute4: [__NOT_SET__] 
    } 
}

来源

2017-04-06 DVK

对于这个问题和之前的问题，你是否被锁定到你当前的“JSONish”结构中，还是可以改变的？我并不是要求改变“JSONish”，而是改变“JSONish”的形状。 –

我的建议是摆脱尝试使用键值对来表示谓词短语。你应该有更多的灵活性与类似的结构：

{ 
    filters: [ 
     { attribute: "attribute2", verb: "IN", values: [val21, val22] }, 
     { attribute: "attribute2", verb: "NOT IN", values: [val21, val22] }, 
     { attribute: "attribute4", verb: "IS NOT SET" }, 
    ] 
}

你想要动词的枚举，当然，和值必须是可选的。如果你需要他们，你可以添加更多的动词，并且你不再给穷人:施加很大的压力。您还可以向客户端提供支持的动词列表以及它们所采用的类型（如果有）的数量，以便客户端可以动态构建UI（如果需要）。

当然，这是一个突破性的变化，这可能是也可能不是问题。

来源

2017-04-06 19:06:56

我不确定我是否可以使用它，但这是API设计的一个非常大的改进; +1 – DVK

@DVK我一直在想这件事。如果你不能引入一个突破性的变化，我认为你将会得到的最好的结果是'filters'（隐含的IN），'unset_filters：[..]'和'not_in_filters'，正如你在https：///stackoverflow.com/questions/43262890/what-would-be-a-good-api-format-for-not-in-clause。希望有人证明我错了。 :-( –

我其实是点了点头，做了一件更好的事情：旧的“过滤器”保持不变，新的“filters_enhanced”的格式与您的答案类似，除非像我的原始格式一样，属性名称是地图中的关键而不是向量中的一个属性，在服务器端，我只需将旧的过滤器转换为带有“IN”谓词的新格式增强过滤器。 – DVK

什么是“IS NOT SET”子句的良好API格式？

回答

相关问题