API设计：以XML表示搜索标准

Question

去年，我的小组开发了一个包含基本搜索功能的Web服务。 所有搜索条件，其中用布尔和组合：

<conditions> 
    <condition name="name1">value1</condition> 
    <condition name="name2">value2</condition> 
<conditions> 

...相当于名1 =值1和2 =值2等

现在，我们已要求扩大搜索功能，让用于更复杂的搜索。 我看到两种合理的方法：

选项1：让用户传递他们自己的SQL查询（无论是全部子句，还是只是'where'）。

例子：

<where>Cost = 5000.00 OR Cost > 5000.00</where> 
<query>SELECT cmis:name FROM cmis:document WHERE cmis:name LIKE '%test%'</query> 

判例：

• SearchSQL.SetWhereClause在IBM的FileNet的API
• Content Management Interoperability Services (CMIS) spec
• ADO使用在各个地方这种做法。例如，recordset.Filter

优点：

• 我们的架构保持简单。我们可以为简单用例保留“<条件>”方法，并添加一个替代语法。
• 我们只是直接在服务器端使用WHERE子句（用于sql注入的清理之后）==更干净的代码服务器端
• 遵循行业标准（是否？CMIS，Microsoft ...任何来自Java世界的东西？ ）

缺点：

• 不正是 “优雅XML”（有没有这样的事情？）。有可能迫使服务的消费者在他们身上做一些骇人的字符串操作，而不是为他们提供更优雅的东西。

选项＃2。修改我们的<条件>的方法，以便在soap请求中提供更详细的查询。

实施例（从FetchXML）：

<filter type='and'> 
    <condition attribute='lastname' operator='ne' value='Cannon' /> 
</filter> 

判例：

• FetchXML
• Ant gets close与<如果>/<别的>

优点：

• 可以说什么最终用户所期望的（一个很好的API的经常标记）
• 可能给最终用户更干净的代码更一致
• 不创建SQL语言的依赖性/后端。保持它抽象

缺点：

• 更重要的XML重建到SQL语句首先意味着用户

我希望实例所需的服务器端代码，先例，优点和缺点为避免主观答案提供了足够的背景。我正在寻找基于标准和最佳实践的答案。

我的问题是：在扩展API时选择一种方法而不是另一种方法的决定性原因？

Answer 1

选项＃2，如果只是出于一个原因：安全。

允许最终用户将任意SQL传递到您的数据库是对灾难的邀请。你要么相信你的用户永远不要犯SQL错误，要么你必须编写代码来确定你将接受哪个SQL以及你将拒绝哪个SQL。

选项＃2将更难设计和实施，但选项＃1保证当某个用户更新重要表中的每个记录时，您会在某个时候憎恨自己。

Answer 2

我同意选项＃1上的DWRoelands从安全角度来看可能是一个坏主意。

我会建议一个选项＃3，类似于您的选项＃2，但使用DSL（域特定语言）。所以你会有这样的：

<condition expression="$firstname='John' and $lastname !='Doe'"/> 

然后服务器将需要一个解析器来编译和运行表达式。您可以自由设计表达式的语法以满足您的需求。

我个人实现了你的选项＃2和DSL之前。我更喜欢DSL，因为它具有灵活性，它使我的XML看起来更干净。你说得对，这种方法需要更多的服务器端编码，但我更愿意做更多的工作，而不是让用户做更多的工作。