Блог

В прошлом году моя группа разработала веб-сервис, который включал базовые функции поиска. Все условия поиска в сочетании с логическим И:

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

… эквивалентно name1=значение1 И name2=значение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
• Спецификация служб взаимодействия управления контентом (CMIS)
• ADO использует этот подход в различных местах. Например, набор записей.Фильтр

Преимущества:

• Наша схема остается простой. Мы могли бы оставить подход «<условия>» на месте для простых вариантов использования и добавить альтернативный синтаксис.
• Мы бы просто использовали предложение WHERE непосредственно на стороне сервера (после очистки для внедрения sql) == более чистый код на стороне сервера
• Соответствует отраслевым стандартам (так ли? CMIS, Microsoft… что-нибудь из мира Java?)

Недостатки:

• Не совсем «элегантный xml» (есть ли что-нибудь подобное?). Потенциально заставляет потребителей сервиса выполнять некоторые хакерские манипуляции со строками на своей стороне, вместо того, чтобы предоставлять им что-то более элегантное.

ВАРИАНТ № 2. Измените наш подход <условия>, чтобы разрешить более детализированные запросы в запросе soap.

Пример (из FetchXML):

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

Прецедент:

• FetchXML
• Ant приближается к <if> / <else>

Преимущества:

• Возможно, более соответствует ожиданиям конечного пользователя (часто признак хорошего API)
• Возможность предоставления конечным пользователям более чистого кода
• Не создает зависимости от языка SQL / серверной части. Сохраняет его абстрактным

Недостатки:

• Требуется больше серверного кода для преобразования XML в инструкцию SQL, которую пользователь имел в виду в первую очередь

Я надеюсь, что приведенные примеры, прецеденты, преимущества и недостатки дают достаточно информации, чтобы избежать субъективных ответов. Я ищу ответы, основанные на стандартах и передовой практике.

Мой вопрос таков: существуют ли окончательные причины для выбора одного подхода вместо другого при расширении API?

Вариант №2, хотя бы по одной причине: безопасность.

Разрешать конечным пользователям передавать произвольный SQL в вашу базу данных — это приглашение к катастрофе. Вы либо доверяете своим пользователям НИКОГДА не допускать ошибок в SQL, либо вам приходится писать код, чтобы определить, какой SQL вы собираетесь принять, а какой отклонить.

Вариант № 2 будет сложнее спроектировать и реализовать, но вариант № 1 гарантирует, что вы возненавидите себя в какой-то момент, когда какой-нибудь пользователь обновит каждую запись в важной таблице.

Я согласен с DWRoelands в том, что вариант № 1, вероятно, является плохой идеей с точки зрения безопасности.

Я бы предложил Вариант № 3, который похож на ваш вариант № 2, но использует DSL (Domain Specific Language). Таким образом, у вас будет что-то вроде:

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

Затем серверу потребуется анализатор для компиляции и запуска выражения. Вы вольны спроектировать синтаксис выражения в соответствии с вашими потребностями.

Я лично реализовал ваш вариант № 2 и DSL ранее. Мне больше нравится DSL из-за его гибкости, и это делает мой XML более чистым. Вы правы в том, что такой подход потребует большего количества кодирования на стороне сервера, но я предпочитаю выполнять больше работы, чем позволять пользователю выполнять больше работы.