Разработка API: выражение критериев поиска в XML - PullRequest
Новая
       16

Разработка API: выражение критериев поиска в XML

2 голосов
/ 26 мая 2011

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

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

... эквивалентно name1 = значение1 И имя2 = значение2 и т. Д.

Теперь нас попросили расширить функцию поиска для более сложных поисков. Я вижу два вероятных подхода:

ВАРИАНТ № 1: разрешить пользователям передавать собственный SQL-запрос (либо полное предложение, либо просто «где»).

Примеры: 

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

Прецедент:

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

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

Недостатки:

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

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

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

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

Прецедент:

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

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

Недостатки:

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

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

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

Ответы [ 2 ]

3 голосов
/ 31 мая 2011

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

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

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

2 голосов
/ 01 июня 2011

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

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

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

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

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

...