Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Форум
    RouterOS
    Генерация "цифр"

    Генерация "цифр"

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Генерация "цифр", RouterOS
     
    boen_robot
    Guest
    #1
    0
    02.05.2013 21:16:00
    Я пытаюсь добавить в свой API-клиент возможность эмулировать номера, создавая и поддерживая индекс отображений "номер на ID". Я читал, что ID не меняются в рамках одной сессии даже после операций CRUD, что, я полагаю, неплохая новость для производительности, но… как генерируется начальный список номеров? Я думал, что ID отсортированы (в порядке возрастания) и это точка отсчета… но, видимо, не так - не только мои PHP-тесты дают вводящие в заблуждение результаты при таком предположении, но и при более внимательном изучении, ID даже не отсортированы в терминале (например, мои первые две простые очереди имеют ID "*4d5" и "*4d6", в то время как очередь ГОРАЗДО позже в списке имеет ID "*102"; все это после того, как я вышел и снова вошел в Winbox, так что ID точно свежие). Так как же вообще генерируется список номеров, если не сортировкой по ID? В каком порядке приходят ответы "print"? Я думал, что они не должны иметь значения… верно? Или это относится только к API-протоколу, а в терминале значение есть? Замечание: возможно, у меня есть обходной путь, включающий создание скрипта, который обрабатывает это, а затем я буду получать результаты, но это очень дорого с точки зрения производительности (не говоря уже о том, что это означает, что пользователям потребуется право на запись, даже если они просто читают), и поэтому я спрашиваю в надежде избежать этого. EDIT: На самом деле, перечитав сейчас API spec, полагаться нужно не на порядок свойств. Следует ли из этого, что я могу полагаться на порядок предложений в ответе "print", чтобы они соответствовали номерам? Это, конечно, похоже на то, что работает в моей версии RouterOS (5.6), но вопрос в том, является ли это намеренным или просто совпадением.
     
     
     
    janisk
    Guest
    #2
    0
    22.07.2013 07:55:00
    Синтаксис API не менялся с момента его появления. Если структура CLI изменится, конечно, API тоже изменится, чтобы отразить эти изменения. Новые функции только расширяют API, добавляя новые возможности, например, запросы, которые вам не придется изучать, если вы не хотите их использовать.
     
     
     
    boen_robot
    Guest
    #3
    0
    17.08.2013 22:58:00
    @tjc Ну, в последней версии моего API-клиента есть и это, для тех, кто чувствует то же самое, но всё же нуждается во взаимодействии с PHP. @janisk Есть хоть какая-то возможность, чтобы и мне ответили на мой вопрос?
     
     
     
    janisk
    Guest
    #4
    0
    19.08.2013 12:18:00
    Порядок идентификаторов, возвращаемых командой ‘find’, соответствует нумерации, которую бы использовал терминал? Это не гарантировано, что порядок будет совпадать с тем, что выдает команда CLI print. Лучше использовать другие идентификаторы, например, содержимое поля комментария, чтобы идентифицировать одно и то же в API и CLI для операторов. Есть еще проблема в том, что номера CLI выдаются только после выполнения команды print для списка. Обычно я использую .id идентификаторы для доступа к правилам. Также, из твоего первого поста - .id поля постоянны для правил, которые добавляются статически на протяжении всего жизненного цикла объекта. Но порядок их выдачи не задан и может варьироваться от списка к списку, иногда нумерация сбрасывается, иногда нет.
     
     
     
    boen_robot
    Guest
    #5
    0
    19.08.2013 13:42:00
    Это не гарантируется, что будет использован тот же номер заказа, что и при использовании команды CLI print. Если я все правильно понимаю, ("API find" = "CLI find") != "CLI print" (с точки зрения порядка ID). Но порядок выдачи не задан и может варьироваться от списка к списку, иногда нумерация сбрасывается, иногда нет. Я это понимаю, но внутри одного списка, при выводе ("print") этого списка, можно ли считать, что порядок элементов, выводимых командой "print" (для этого конкретного списка), всегда соответствует порядку, который показывает CLI? То есть, например, может ли порядок ответов, полученных с помощью "/queue/simple/print", соответствовать порядку, который выдаёт "/queue simple print" в CLI (предполагая, что между ними не происходит добавления, перемещения или удаления элементов)? Или, если говорить другими словами, "API print" = "CLI print" (с точки зрения порядка ответов)? Какой бы был более надежный способ получения ответов в упорядоченном виде, если не этот? Обычно я использую .id ID-номера для доступа к правилам. Да, но я делаю это ради тех, кто уверен, что нацелен на правильную запись, и готов подстрелить себя в ногу, если это не так.
     
     
     
    janisk
    Guest
    #6
    0
    21.08.2013 07:08:00
    Нет никакой гарантии, что порядок элементов будет таким же, как между командами print в API или CLI. Есть некоторые списки объектов, которые это обещают – например, `/ip firewall`, где можно перемещать элементы, и print выдаст корректный порядок объектов. Везде остальное делать какие-либо предположения невозможно. Поэтому, используя вашу формулу: Случай A - “CLI print” != “CLI print позже” != “API print”. Это связано с логикой, согласно которой CLI не является сущностью, которая заказывает/управляет элементами. Выполнение команд “/ip firewall filter”, “/ip firewall mangle”, “/ip firewall nat” выдаст одинаковый порядок каждый раз. Поэтому случай B - “CLI print” === “CLI print позже” === “API print”.
     
     
     
    boen_robot
    Guest
    #7
    0
    21.08.2013 09:50:00
    Понял. Спасибо. Ну, в таком случае, у меня есть предложение по новой функции. Добавьте в API возможность получения доступных команд и/или меню и/или аргументов из контекста, подобно “?” в терминале. Возможно, даже сделайте это как “?”. Пример потока протокола: /ip/firewall/?

    !re
    =name=nat
    =type=menu
    =description=Network address translation

    !re
    =name=export
    =type=command
    =description=Print or save an export script that can be used to restore configuration

    ...

    !done

    /ip/firewall/export/?

    !re
    =name=file
    =type=command-arg
    =optional=yes
    =description=File name

    !re
    =name=compact
    =type=command-arg
    =optional=yes
    =description=

    ...

    !done

    /ip/zzz/?

    !trap
    =help=yes
    =msg=No such item

    !done (внутри !trap есть “help=yes”, чтобы было понятно, что эта версия поддерживает команду “/?”, но она всё равно не работает для этого конкретного элемента; это не обязательно должен быть именно этот индикатор, главное, чтобы он отличался от текущего вида ошибки для несуществующих команд, и не только в плане сообщения) Или, может быть, сделать API-специфичную команду, например, “/help”, которая будет получать контекст в качестве аргумента, например, /help
    =context=/ip/firewall В любом случае… Это позволит мне обнаруживать, есть ли команда "move" в текущем меню, и действовать соответствующим образом, и это также позволит сделать какие-то другие классные штуки… например, возможно, я мог бы предварительно проверять команды или, что еще лучше, - предварительно генерировать объекты (ORM, here we go!).
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры