+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

[Ошибка/предложение по API] Регулярные выражения в запросах

[Ошибка/предложение по API] Регулярные выражения в запросах, RouterOS

boen_robot

Guest

17.11.2011 14:22:00

Недавно мне сообщили, что API не поддерживает регулярные выражения в запросах. Лично мне это пока не нужно, но другим такое важно, и, по моему мнению, это вполне разумное предложение для реализации. Причины для добавления этой функции и примеры использования совпадают с теми, ради которых вообще существуют запросы — ограничить объём памяти, потребляемой клиентами API, и дать RouterOS возможность минимизировать сетевой трафик. Чтобы сохранить согласованность с другими операциями, по моему мнению, лучше всего использовать синтаксис вроде ?~name=pattern.

[редактирование] Мне сказали, что следующий синтаксис работает для фильтрации вывода по регулярному выражению через API: ~name~"pattern". Однако это скорее баг API, чем полноценная функция, так как синтаксис совершенно не совпадает с остальной частью API. К тому же это не входит в спецификацию.

[редактирование]

amr

Guest

26.02.2012 20:57:00

Полностью с вами согласен! Мы запускаем routerOS на оборудовании не от Mikrotik — думаю, серверы вполне способны работать с регулярными выражениями. Может, кто-то подтвердит, что поиск по регулярным выражениям или частичное совпадение не работает? “~key~value” ничего не фильтрует, а “?~key~value” ничего не возвращает. Через терминал это работает: /ip address print where address~"10.10". Так в чем же тогда дополнительная «нагрузка» при использовании API?

janisk

Guest

04.06.2012 12:59:00

Это многое даёт. Как я уже объяснял раньше — запускать их на стороне клиента дешевле, чем на стороне сервера, учитывая, что запросы возможны. Я не видел ни одного мощного роутера, который бы просто стоял без дела. Обычно всё наоборот — тебе нужен мощный роутер, и когда хочешь автоматизировать какие-то задачи, стараешься добавить как можно меньше дополнительной нагрузки (не связанной с маршрутизацией или сетью), чтобы не пришлось апгрейдить остальное железо.

boen_robot

Guest

04.06.2012 13:30:00

Но регулярные выражения доступны в скриптинге/SSH... Я бы предположил, что если их внедрят в API, то будет использоваться тот же движок регулярных выражений, так откуда тогда разница? То есть в обоих случаях у нас есть автоматизированное действие вне маршрутизации. Единственное отличие — в скриптинге/SSH результаты не отправляются по сети, а сохраняются для дальнейшей обработки (которая, в свою очередь, может включать отправку по сети, особенно если речь про вывод SSH). Или я что-то упускаю? Если штрафы слишком велики в некоторых сценариях, люди всегда могут просто... не знаю... не использовать эту функцию в таких ситуациях. Предупреждение в документации, на мой взгляд, вполне бы хватило, чтобы предупредить пользователей.

chojrak11

Guest

31.03.2015 04:05:00

Да, этот несоответствие странное. Так я могу создать «нагрузку» на роутер через SSH, а вот через API — нет? Где логика? Это можно было бы реализовать максимум за полчаса кодинга и дать пользователям самим решить, нужно им это или нет. Все эти авторитарные аргументы похожи на корпорацию, которая думает, что лучше знает, что полезно её клиентам и пользователям. А @janisk отлично понимает, что его аргументы вообще не имеют смысла, но почему-то уже много лет их защищает. Если ты правда считаешь, что регулярные выражения создают большую нагрузку на роутер, то оператор «~» надо удалить из скриптового языка тоже. А потом вообще убрать скрипты, потому что они тоже могут грузить на 100%, например, с помощью бесконечного цикла. Не считай своих клиентов тупыми, просто добавь, пожалуйста, запрашиваемую функцию.

legrang Guest	#6 0 12.07.2015 18:16:00 Это снова всплыло, смотрите: http://forum.mikrotik.com/t/operator-in-api-calls/89533/2 Закон Мура и постоянные вопросы по этому поводу должны вполне ясно дать понять, что эту функцию стоит пересмотреть? Gideon

Deantwo

Guest

19.01.2016 07:36:00

Если только движок скриптов/CLI не полностью отделён от API и не работает совершенно по-другому, я не вижу смысла в таком дополнении. Человек, который говорил тебе это «давным-давно», возможно, был прав тогда, но сейчас это явно уже не проблема. Ты ещё предполагаешь, что клиент всегда мощнее роутера, а это вовсе не обязательно. Думаю, RaspberryPi с использованием API скорее предпочёл бы, чтобы работа выполнялась на роутере. В любом случае, очень хотелось бы получить обновление по этому вопросу/запросу.

chojrak11

Guest

20.01.2016 10:56:00

Ребята, да не дурачьтесь, уже сделайте этот regex-мэтчинг для API. И когда решите заняться этим, забудьте про этот отстойный синтаксис GNU Extended Regex, берите сразу широко распространённый синтаксис, совместимый с PCRE.

boen_robot

Guest

20.01.2016 11:11:00

Если честно, они уже используют POSIX регулярные выражения в скриптах… Переход на PCRE сломает кучу скриптов, а использовать PCRE только для API, оставляя POSIX для скриптинга — это запутает людей. Если API использует POSIX регулярные выражения, этого, на мой взгляд, достаточно. Если уж переход на PCRE и будет, то только в версии v7, для API и скриптов сразу.

chojrak11 Guest	#10 0 20.01.2016 11:14:00 Хорошие замечания. Я забыл про скрипты и L7-матчинг. Ненавижу POSIX регулярные выражения, они неправильные во всех отношениях. Так что давайте голосовать за PCRE для RouterOS v7.

mrz Guest	#11 0 20.01.2016 13:51:00 Пожалуйста, наберитесь терпения, в ROSv7 появятся новые функции.

boen_robot

Guest

#12

20.01.2016 13:55:00

Ой? Включая это сообщение? (Где же эмодзи с фейерверком, когда он так нужен…) Отлично!!! Знать, что это все же случится — вот чего все и хотели… В отличие от того, что у нас было до сих пор: «Нет, не будет, извините».

legrang

Guest

#13

20.01.2016 14:07:00

Как разработчику, который внедряет API (а не просто его использует), было бы здорово получить какую-нибудь предварительную информацию, чтобы я мог адаптировать Java API и быть готовым выпустить обновление сразу после выхода версии 7.0 из беты, намёк, намёк. Но есть хорошие новости!

Praktimarc

Guest

#14

13.01.2025 16:03:00

Все еще нет новостей по этому поводу? Я пользуюсь этим API с 2013 года. Как разработчик программного обеспечения, я просто не могу понять, почему эту проблему нельзя решить! Фильтрация данных должна происходить до их передачи — в этом суть. Могу сказать, что решение на стороне клиента — это плохой вариант, особенно при передаче больших объемов данных через API, поскольку часть данных теряется. Строки отрезаются и так далее. Я использую это в системе поддержки, чтобы отображать устройства, подключенные через отдельный cap-интерфейс. Очень раздражает делать обходные решения, пока кто-то избегает внедрения этого и придумывает плохие оправдания.

Amm0 Guest	#15 0 13.01.2025 22:00:00 Ну что ж, народ проявлял терпение… Но даже новый REST API, который заимствует синтаксис запросов API, тоже не поддерживает регулярные выражения. Так что он полезен не только по сравнению со старым API, ведь я предполагаю, что REST просто проксирует родной API. Если бы API поддерживал регулярки, думаю, они бы работали и в REST API. Значит, это можно «решить», вопрос лишь в приоритетах. Даже Winbox4 не поддерживает запросы с регулярками.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры