По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Что такое API?
Поскольку мы говорим про REST API, то наше определение API не будет сильно выходить за тематику сетей. Подробнее про API можно прочитать тут.
API означает Application Programming Interface. API задает связь между программами для возможности передачи данных.
То, что программа имеет API, подразумевает, что она передает часть своих данных для использования клиентом. Клиентом может быть фронтенд часть той же самой программы или другая внешняя программа.
Для получения этих данных необходимо отправить структурированный запрос на API. Если запрос удовлетворят желаемым требованиям, то ответ, содержащий данные, будет отправлен туда откуда был сделан запрос. Обычно ответ представлен в формате JSON или XML.
В некоторых случаях, для получения доступа к внешнему API, от вас может потребоваться авторизация.
Каждый API имеет документацию, в которой говорится какие данные доступны и как структурировать свой запрос для получения правильного ответа.
Примеры API
Рассмотрим в качестве примера реальную ситуацию.
Представьте посещение нового ресторана. Вы пришли, чтобы заказать еду, а поскольку вы здесь впервые, то точно не знаете какие блюда они подают.
Официант дает вам меню, в котором можно выбрать, чтобы вы хотели съесть. После того, как выбор сделан, официант отправляется на кухню и приносит вам еду.
В данном случае официант - это API, который обеспечивает вашу взаимосвязь с кухней. Документация API - это меню. Запрос выполняется в тот момент, когда вы отмечаете желаемые блюда, а ответ - это блюда, которые вам принесли.
Что такое REST?
REST означает REpresentational State Transfer (передача состояния представления). Это стандарт, который определяет форму и работу процессов, позволяющих нам взаимодействовать с данными на вебсерверах.
Приведенное выше определение может выглядеть не так сложно или «профессионально», как то, что вы могли встретить в интернете, но главное, чтобы вы поняли основную цель REST API.
API, который удовлетворяет некоторым или всем шести руководящим ограничениям REST считается RESTful.
Мы можем взаимодействовать с серверами при помощи протокола HTTP. Благодаря этим протоколам мы можем Create (создавать), Read (читать), Update (обновлять) and Delete (удалять) данные – также известные как CRUD операции.
Но каким образом мы можем выполнять CRUD операции и взаимодействовать с данными на сервере?
Мы делаем это, посылая HTTP запросы, и это тот самый момент, когда REST начинает действовать. REST упрощает процесс взаимодействия с сервером, предоставляя различные HTTP методы/операции/команды, с помощью которых можно посылать запросы на сервер.
Как взаимодействовать с сервером, используя REST API?
Как мы уже обсуждали, REST API облегчает процесс взаимодействия с сервером, предоставляя нам различные методы HTTP запросов. Наиболее распространенные методы:
GET: Метод get используется для Чтения данных с сервера.
POST: Метод post используется для Создания данных.
PATCH/PUT: Метод patch используется для Обновления данных.
DELETE: Метод delete используется для Удаления данных.
Эти методы предоставлены нам REST, что упрощает выполнение CRUD операций. Таким образом:
Создать => POST
Прочитать => GET
Обновить => PATCH/PUT
Удалить => DELETE
Если мы хотим сделать запрос на сервер, например, для получения данных, то мы отправляем запрос GET на узел/источник данных на сервере. Узел данных аналогичен URL.
Если запрос составлен корректно, то сервер отправит нам в ответ запрашиваемые данные. Также он отправит код состояния, где 200 - это успешное выполнение, а 400 - это ошибка пользователя.
Пример запроса на JSONPlaceholder API, используя JavaScript:
fetch('https://jsonplaceholder.typicode.com/todos/1')
.then(response => response.json())
.then(json => console.log(json))
При выполнении запроса с использованием fetch API по умолчанию используется метод GET, поэтому мы можем не указывать его явно. Но мы должны будем это сделать при использовании других методов.
В приведенном выше примере, узел данных - это https://jsonplaceholder.typicode.com, а запрашиваемые нами данные - это один элемент todo. Данные будет получены в JSON формате.
Если бы мы использовали запрос POST, тогда бы мы использовали метод POST, а в теле запроса находились бы данные, которые мы создали для отправки на сервер.
Для удаления нам потребуется использовать соответствующий запрос, содержащий id элемента todo, который мы хотим удалить. Например:
fetch('https://jsonplaceholder.typicode.com/posts/3', {
method: 'DELETE',
});
Для обновления данных нужно, чтобы запрос содержал id и данные для обновления. Как в этом примере:
fetch('https://jsonplaceholder.typicode.com/posts/5', {
method: 'PATCH',
body: JSON.stringify({
title: 'new todo',
}),
headers: {
'Content-type': 'application/json; charset=UTF-8',
},
})
.then((response) => response.json())
.then((json) => console.log(json));
Заключение
В этом руководстве вы узнали, что такое REST и как он помогает нам эффективно взаимодействовать с сервером.
Мы дали определение API и рассмотрели пример, который помог объяснить его смысл. Мы также узнали некоторые методы REST для создания, чтения, обновления и удаления данных, хранящихся на сервере.
Рассказываем про ещё один полезный инструмент на роутерах MikroTik - отправку e-mail сообщений по протоколу SMTP. Данный инструмент может быть использован для отправки на почту периодических бэкапов или же задействован для написания каких-нибудь скриптов.
В интерфейсе WinBox, утилита Email расположена в разделе Tools → Email:
Из командной строки - /tool e-mail.
Первым делом нужно настроить сервер исходящей почты по протоколу SMTP. Доступны следующие параметры настройки:
address - IPv4/v6 адрес, SMTP сервера;
from - имя или название почтового ящика, который будет показан получателю;
password - пароль, который используется для аутентификации на SMTP сервере. В этом случае аутентификации не будет шифроваться. Для включения шифрования можно использовать функцию start-tls;
port - порт SMTP сервера, по умолчанию 25;
start-tls - может принимать значения no, yes и tls-only - разрешает только TLS шифрования без поддержки SSL;
user - имя пользователя, которое будет использоваться для аутентификации на SMTP сервере.
Когда сервер будет настроен, можно начинать отправлять письма. Все параметры при отправке писем идут после команды /tool e-mail send:
body - тело письма
cc - данный параметр позволяет поставить в копию дополнительных получателей;
file - позволяет добавлять один или несколько файлов во вложении к письму;
from - название или почтовый адрес, который будет показан как отправитель. Если ничего не указано, то будет взят from, который указывался при настройке сервера SMTP;
password - пароль, который используется для аутентификации на SMTP сервере. Если ничего не указано, то будет взят password, который указывался при настройке сервера SMTP;
port - порт SMTP сервера. Если ничего не указано, то будет взят port, который указывался при настройке сервера;
server - адрес SMTP сервера. Если не указано, то используется параметр сервера, указанный при настройке;
start-tls - использовать ли TLS шифрование;
subject - тема письма;
to - адрес получателя, которому предназначено письмо;
user - имя пользователя, для аутентификации на сервере. Если не указано, то будет использоваться user из настроек сервера.
Теперь давайте применим механизм отправки писем на практике и создадим скрипт, который будет каждый день высылать файл с резервной копией конфигурации нам на почту.
Вот как настройка будет выглядеть в командной строке:
tool e-mail> set server=192.168.1.34 set port=25 from=”mnmikrotik@mndomain.ru”
Теперь добавим новый скрипт, который будет делать бэкап конфигурации роутера:
/export file=export /tool e-mail send to="mnadmin@mndomain.ru"subject="$[/system identity get name] export" body="$[/system clock get date] configuration file" file=export.rsc
Добавим скрипт на выгрузку конфигурации в планировщик:
/system scheduler add on-event="export-send" start-time=00:00:00 interval=24
Готово, теперь каждый день нам на почту mnadmin@mndomain.ru будет приходить свежая выгрузка резервной копии конфигурации нашего роутера.
Для того, чтобы настроить отправку писем на почтовый ящик, требующий TLS шифрования (как например Google mail), нужно настроить следующие параметры отправителя:
/tool e-mail set address= 192.168.1.34
set port=587
set from=mnaddress@gmail.com
set user= mikrotik
set password= supersecurepass
При отправке письма на такой ящик, необходимо указать параметр start-tls.
send to=mnadmin@mndomain.ru subject="HW!" body="Hello World!" start-tls=yes
Если Вы предпочитаете настраивать роутер с помощью интерфейса WinBox, то откройте Tools → Email и настройте параметры сервера:
Далее заходим в System → Scripts и добавляем новый скрипт на выгрузку конфигурации:
Добавляем скрипт в планировщик, чтобы он срабатывал каждый день:
Всем привет! Недавно одну из наших статей мы посвятили рассказу о Route Patterns. Сегодня мы продолжим рассматривать механизм маршрутизации звонка в Cisco Unified Communications Manager (CUCM), и рассмотрим, что происходит с вызовом после того как он попал под определенный паттерн – а именно про Route List и Route Group.
Рассмотрим, как происходит процесс маршрутизации.
После набора номера в Route Patterns происходит сверка с заданными паттернами и выбирается подходящий, который указывает на Route List, который указывает на группы Route Group, которые в свою очередь указывают на устройства, шлюзы и транки.
Настройка Route Group
Для создания группы нужно перейти во вкладку Call Routing → Route/Hunt → Route Group и нажимаем Add New. Тут указываем название группы и в поле Distribution Algorithm выбираем, по какому алгоритму будут распределяться устройства – Top Down или Circular. Сами устройства, транки или шлюзы выбираем в поле Available Devices и для добавления в группу нажимаем кнопку Add to Route Group. После этого добавленное устройство появляется в поле Selected Devices. Для сохранения настроек нажимаем Save.
Настройка Route List.
Чтобы создать список нужно вкладку Call Routing → Route/Hunt → Route List и нажать Add New. Здесь указываем название, описание и группу (по умолчанию – Default). После нажатия Save внизу появляется поле Route List Member Information, в котором нужно нажать кнопку Add Route Group.
В открывшемся окне в строке Route Group выбираем необходимую группу и нажимаем Save. Также в этом окне содержатся настройки трансформации номеров. После этого добавленная группа появится в поле Selected Groups. Затем добавляем остальные группы и сохраняем настройки.
Проверить получившийся маршрут можно перейдя во вкладку Call Routing → Route Plan Report. Здесь можно увидеть список паттернов Route Patterns, список Route List на который они указывают, группы Route Groups, которые содержит список и устройства, шлюзы и транки, указанные в группе. Это наглядно показывает в иерархическом порядке структуру маршрутизации.