API设计：以XML表示搜索条件

如何解决API设计：以XML表示搜索条件

| 去年，我的小组开发了一种包含基本搜索功能的Web服务。所有搜索条件都结合了布尔AND：

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

...相当于name1 = value1 AND name2 = value2等现在，我们被要求扩展搜索功能以允许更复杂的搜索。我看到两种可行的方法：选项＃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>

先例： IBM FileNet API中的Searchsql.SetWhereClause 内容管理互操作性服务（CMIS）规范 ADO在各种地方都使用这种方法。例如，recordset.Filter 优点：我们的架构保持简单。对于简单的用例，我们可以保留\“ \”方法，并添加替代语法。我们将直接在服务器端使用WHERE子句（在清理sql注入之后）==更干净的代码服务器端遵循行业标准（是吗？CMIS，Microsoft ... Java世界中有什么？）缺点：不完全是“优雅的xml”（有这样的东西吗？）。潜在地迫使该服务的消费者在他们的一边进行一些骇人听闻的字符串操作，而不是给他们提供更优雅的东西。选项＃2。改进我们的方法，以允许在soap请求中进行更详细的查询。示例（来自FetchXML）：

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

先例：提取XML 蚂蚁与 / 接近优点：可以说与最终用户的期望更一致（通常是优质API的标志）可能为最终用户提供更清晰的代码不会创建对sql语言/后端的依赖。保持抽象缺点：首先需要更多的服务器端代码，才能将XML重构为用户想要的sql语句我希望这些示例，先例，优点和缺点能提供足够的背景，以避免主观回答。我正在寻找基于标准和最佳实践的答案。我的问题是：在扩展API时，是否有确定的理由选择一种方法而不是另一种方法？

解决方法

选项＃2（如果仅出于以下原因）：安全性。允许最终用户将任意SQL传递到您的数据库是灾难的诱因。您要么让您的用户相信永远不要在SQL中犯错误，要么您必须编写代码来确定要接受的SQL和要拒绝的SQL。选项＃2较难设计和实现，但选项＃1保证当某些用户更新重要表中的每条记录时，您有时会讨厌自己。 ,从安全角度来看，我同意DWRoelands关于选项＃1的想法很糟糕。我建议使用与您的选择2类似的选择3，但使用DSL（特定于域的语言）。因此，您将获得类似以下内容的信息：

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

然后，服务器将需要具有解析器来编译和运行表达式。您可以自由设计表达式的语法以适合您的需求。我已经亲自实现了您的选择2和DSL。由于它的灵活性，我更喜欢DSL，它使我的XML看起来更干净。没错，这种方法将需要更多的服务器端编码，但是我宁愿做更多的工作，也不愿让用户做更多的工作。