По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Что такое 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 для создания, чтения, обновления и удаления данных, хранящихся на сервере.
В больших корпоративных сетях могут использоваться несколько протоколов внутренней маршрутизации. Такая практика часто встречается при слиянии двух компаний. Чтобы компьютеры в одном домене маршрутизации (далее просто «домен») видели хосты в другом домене применятся так называемая редистрибуция. Эта функция позволяет маршрутизатору выбрать маршрут, выученный через один протокол маршрутизации, например, EIGRP и добавить в его в список анонсируемых сетей в другой, например, OSPF. Эта операция выполняется на маршрутизаторах, который смотрят в обе сети и называются точкой редистрибуции (Redistirbution Point). Маршрутизаторы, которые занимаются анонсированием сетей из одного домена в другой используют для этого таблицу маршрутизации. Другими словами, если маршрутизатор не найдет путь до какой-то сети в своей таблице, то он не будет анонсировать его в другой домен.
Схема сети
Для построения отказоустойчивой сети обычно применяются два или более маршрутизатора, которые занимаются перебросом маршрутной информации с одного домена в другой. В такой ситуации может образоваться так называемая петля маршрутизации. Поясним на рисунке:
В данном случае пакеты из маршрутизатор 2, чтобы добраться до сети Х, которая находится в том же домене делает круг через RD1 > R1 > RD2 > Subnet X. Это происходит потому, что маршрут, объявленный RD1 в Домен маршрутизации 2, имеет меньшее административное расстояние (Administrative Distance, AD), чем маршруты, объявленные роутерами из того же домена. Далее рассмотрим в каких случаях возможно такое.
Как избежать петель?
Один из самых лёгких методов для избегания петель маршрутизации это при добавлении маршрутов из одного домена в другой более высокой метрики.
В данном случае маршрутизаторы RD1 и RD2 при анонсировании маршрутов, выученных протоколом RIP в домен OSPF, назначают им метрику 500. И наоборот, из домена OSPF в домен RIP маршруты анонсируются с метрикой 5.
Второй способ – это административное расстояние. Любой маршрут, который добавляется в таблицу маршрутизации роутера, сопоставляется с административным расстоянием. Если роутер получил несколько маршрутов в одну и ту же сеть с одной и той же длиной префикса, то в таблицу попадают маршруты с меньшим AD. Маршрутизатор не учитывает метрику. Вместе с этим, AD – это локальное значение для каждого роутера и не объявляется соседним маршрутизаторам. В таблице ниже приведены административные расстояния для всех типов маршрутов на роутерах Cisco.
Тип маршрутаАдминистративное расстояниеConnected (подключённый)0Static (Статический)1EIGRP Summary route5eBGP (external BGP)20EIGRP (internal)90IGRP100OSPF110IS-IS115RIP120EIGRP (external)170iBGP (internal BGP)200
Настройки AD по умолчанию для протокола EIGRP при анонсировании маршрутов в OSPF и RIP предотвращают образование петель маршрутизации.
На рисунке выше подсеть 172.16.35.0/24 анонсируется через RD1 в домен OSPF. Маршрутизатор R2 в свою очередь анонсирует выученную через external OSPF сеть роутеру RD2. Но RD2 уже выучил маршрут до сети 35.0 через EIGRP, у которого административное расстояние равно 90, что меньше чем AD OSFP, которое равно 110. Таким образом RD2 не добавит маршрут, полученный у R2 с AD 110 в таблицу маршрутизации и соответственно не будет редистрибутировать обратно в EIGRP. Таким образом логику работы маршрутизатора RD2 можно сформулировать следующим образом:
RD2 считает маршрут, полученный по EIGRP лучшим, так как у него меньшее административное расстояние, и добавляет его в таблицу маршрутизации.
RD2 не будет анонсировать маршрут, полученный через OSPF, так как его нет в таблице маршрутизации.
В силу своей специфик, протокол EIGRP также предотвращает образование петель маршрутизации при редистрибуции из OSPF и RIP. Как было указано на таблице выше, внешние маршруты в EIGRP имеют административное расстояние равным 170.
В данном случае маршрутизатор RD2 выучил два маршрута в сеть 192.168.11.0/24. Один через R2 в домене OSPF с AD равным 110, второй через R1 в домене EIGRP с административным расстоянием равным 170-ти. Действуя по указанной выше логике, RD2 добавит в таблицу маршрутизации сеть 11.0 выученный у роутера R2 предотвращая таким образом образование петли.
Если в случае EIGRP-OSPF, EIGRP-RIP нам удалось без особых усилий предотвратить петлю маршрутизации, то в случае OSPF-RIP всё немного сложнее. Так как OSPF для всех типов маршрутов использует один показатель AD – 110, то при редистрибуции между RIP и OSPF избежать петель удается только изменение административного расстояния протоколов маршрутизации. Делается это командой distance. Для изменения показателя AD для внешних маршрутов, в интерфейсе настройки OSPF прописываем команду distance external ad-value. Значение, указанное параметром должно быть больше, чем у RIP (120).
Но не редки случаи, когда в сети работают более двух протоколов маршрутизации. В таких случаях значения AD по умолчанию не помогают. На рисунке ниже сеть 172.20.0.0/16 выучена протоколом EIGRP как внешний через RIP с АР (Административное Расстояние) равным 170. В свою очередь RD1 анонсирует данную сеть в домен OSPF с АР равным 110. RD2 же вместо маршрута с АР 170, полученного из домена EIGRP в таблицу добавляет маршрут с АР 110, полученный из домена OSPF. При таком раскладе маршрутизатор R4 получает два маршрута в одну и ту же сеть с одним и тем же АР. И в случае если метрика RD2 лучше, то R4 отправке пакетов в сеть 172.20 будет использовать более длинный путь. Нужно заметить, что это только в том случае, когда домены расположены именно в указанном порядке.
В таких случаях применяется настройка административного расстояния в зависимости от маршрута. Как было указано выше, для изменения АР используется команда distance. Эта команда принимает несколько параметров:
distance distance ip-adv-router wc-mask [ acl-number-or-name ]
В данной команде обязательным параметром является IP соседнего маршрутизатора. Если IP адрес анонсирующего маршрутизатора совпадёт с указанными в команде, то для маршрутов, полученных от этого соседа данный роутер назначит указанный в команде АР.
Рассмотрим указанный случай на практике. Детальная топология сети, показанная выше, указана на рисунке, а конфигурацию можете скачать по ссылке ниже:
Скачать файлы конфигрурации
Для начала просмотрим с каким АР RD1 выучил маршрут до сети 172.20:
Как видим, RD1 добавил в таблицу маршрутизации маршрут, выученный через OSPF, вместо EIGRP, так как АР у OSPF меньше. Теперь изменим поведение маршрутизатора и посмотрим, как это повлияет на таблицу маршрутизации.
ip access-list standard match-172-20
permit host 172.20.0.0
router ospf 2
distance 171 1.1.1.1 0.0.0.0 match-172-20
P.S. В GNS скорее всего придётся выключить, затем включить интерфейс, смотрящий в OSPF домен, чтобы изменения применились. В реальной сети всё работает правильно.
Поясним, что мы написали выше. Со стандартным списком доступа всё понятно. Команде distance параметром задали 171 – административное расстояние. Затем идет router id маршрутизатора, который анонсирует сеть 172.20. В нашем случае это маршрутизатор RD1. Таким образом, OSPF посмотрит полученный LSA и, если там увидит идентификатор маршрутизатора RD1, а также сеть, которая указана разрешённой в списке доступа, то применит этому маршруту расстояние 171.
Отметим, что указанную конфигурацию нужно сделать на всех роутерах, которые занимается распределением маршрутов и для всех сетей их третьего домена.
В том случае, если на вашем предприятии организован мощный отдел продаж и ежедневно вы обрабатываете большое количество вызовов, то база данных, в которую складываются записи CDR (Call Detail Record) начинается переполняться и наращивать объем. Со временем, это может негативно сказаться на производительности сервера, приводя к замедлению обработки процессов резервного копирования и обновления системы.
Если вы не хотите удалять старые записи в базе данных, то элегантным решением данной проблемы будет перемещение базы данных для CDR на отдельный сервер. О том, как это осуществить мы расскажем в этой статье.
Рабочие условия
Предположим, что в нашем корпоративном контуре имеются следующие виртуальные машины:
192.168.1.2 - сервер IP – АТС Asterisk с графической оболочкой FreePBX;
192.168.1.3 - сервер, на котором развернута база данных MySQL;
Поддерживаемые типы баз данных это MySQL (MariaDB) и PostgreSQL;
Предварительно, настройте разрешения на подключения с IP – адреса АТС (файл pg_hba.conf в PostgreSQL и командно через консоль в случае MySQL) и создайте пользователя freepbxuser. Произведем тест на связность. Дадим команду с консоли сервера Asterisk:
mysql --host=192.168.1.3 -ufreepbxuser -p asteriskcdrdb
Введите пароль для подключения. Если все ОК, переходим к настройке FreePBX.
Настройка FreePBX
Переходим в раздел Settings → Advanced Settings. Убеждаемся, что параметры Display Readonly Settings и Override Readonly Settings установлены в значение Yes.
Remote CDR DB Host - IP – адрес хоста, на котором развернута база данных. В нашем примере это 192.168.1.3;
Remote CDR DB Name - имя базы данных. Укажите здесь asteriskcdrdb;
Remote CDR DB Password - пароль для подключения к MySQL от пользователя freepbxuser;
Remote CDR DB Port - порт, на котором база данных на удаленном хосте слушает запросы;
Remote CDR DB Table - таблица, внутри БД, с которой мы будет работать. Указываем здесь cdr;
Remote CDR DB Type - тип базы данных. Мы указываем MySQL;
Remote CDR DB User - имя пользователя, под которым мы производим подключение;
Более подробно почитать про базу данных asteriskcdrdb вы можете почитать в этой статье;
Сохраняем изменения и переходим в консоль сервер АТС. Останавливаем FreePBX:
fwconsole stop
Редактируем файл odbc.ini. Там, в параметре server, нам необходимо указать IP – адрес хоста, на котором у нас развернута внешняя БД:
vim /etc/odbc.ini
[MySQL-asteriskcdrdb]
Description=MySQL connection to 'asteriskcdrdb' database
driver=MySQL
server=192.168.1.3 //замену производим вот тут
database=asteriskcdrdb
Port=3306
Socket=/var/lib/mysql/mysql.sock
option=3
Charset=utf8
Сохраняем изменения в файле и запускаем FreePBX:
fwconsole start
Теперь остается только проверить функционал. Сделайте пару тестовых звонков и проверьте их наличие в БД на удаленном хосте.