По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
REST API – один из самых распространенных типов доступных веб-сервисов, но проектировать их сложно. Они позволяют разным клиентам, включая браузер, настольные приложения, мобильные приложения и практически любое устройство с подключением к Интернету, взаимодействовать с сервером. Именно поэтому очень важно правильно проектировать REST API, чтобы в будущем не было проблем.
Создание API с нуля может оказать непосильной задачей из-за большого количества вещей, которые необходимо учесть – от базовой безопасности до использования правильных методов HTTP, реализации аутентификации, определения того, какие запросы и ответы среди многих других принимаются и возвращаются. В этой статье я очень постарался сжать материал в 15 пунктов с важными рекомендациями, которые позволят создать хороший API. Все рекомендации никак не зависят от языка, поэтому потенциально применимы к любой платформе или технологии.
1. Обязательно используйте имена существительные в названиях путях к конечным точкам
Вам всегда следует использовать имена существительные, которые обозначают объект, который вы извлекаете или которым вы манипулируете. В качестве имени пути всегда предпочтительнее использовать множественное число. Избегайте использования глаголов в названиях путях к конечным точкам, потому что наш метод HTTP-запроса уже является глаголом и по сути не добавляет никакой новой информации.
Действие должно быть произведено с помощью методов HTTP-запроса. Наиболее распространенными являются методы GET, POST, PATCH, PUT и DELETE.
GET извлекает ресурсы
POST отправляет новые данные на сервер
PUT/PATCH модифицируют уже существующие данные
DELETE удаляет данные
Глаголы сопоставляются с функциями CRUD (Create, read, update и delete).
Помня об этих принципах, мы должны создавать маршруты типа GET /books для получения списка книг, а не GET /get-books или GET /book. Аналогично, POST /books - для добавления новой книги, PUT /books/:id - для модификации полных данных книги с заданным идентификатором (id), а PATCH /books/:id обновляет частичные изменения в книге. И наконец, DELETE /books/:id предназначен для удаления существующей книги в заданным идентификатором.
2. JSON как основной формат отправки и получения данных
Несколько лет назад прием и ответы на запросы API выполнялись в основном в XML. Но сейчас «стандартным» форматом для отправки и получения данных API в большинстве приложений стал JSON. Поэтому наш второй пункт рекомендует убедиться, что конечные точки возвращают формат данных JSON в качестве ответа, а также при приеме информации через полезную нагрузку HTTP-сообщений.
Несмотря на то, что FormData хорошо подходит для отправки данных от клиента, особенно если нам нужно отправлять файлы, они не очень подходят для текста и чисел. Нам не нужны FormData для их передачи, так как в большинстве фреймворков можно передавать JSON непосредственно на стороне клиента. При получении данных от клиента нам необходимо убедиться, что клиент правильно интерпретирует данные JSON, и для этого при выполнении запроса в заголовке ответа Content-Type должен быть установлен на application/json.
Стоит еще раз упомянуть исключение, когда мы пытаемся отправлять и получать файлы между клиентом и сервером. В этом конкретном случае нам необходимо обрабатывать файл ответа и отправлять FormData с клиента на сервер.
3. Используйте коды состояний HTTP
Коды состояний HTTP всегда полезно использовать для того, чтобы указать на выполнение или невыполнение запроса. Не используйте слишком много кодов состояний и всегда используйте одни и те же коды для одних и тех же результатов в API. Вот некоторые примеры:
200 – общее выполнение
201 – успешное создание
400 – неверные запросы от клиента, такие как неверные параметры
401 – несанкционированные запросы
403 – отсутствие прав доступа к ресурсам
404 – отсутствуют ресурсы
429 – слишком много запросов
5хх – внутренние ошибки (их следует избегать насколько это возможно)
В зависимости от ситуаций их может быть и больше, но ограничение количества кодов состояний помогает клиенту использовать более предсказуемый API.
4. Возвращайте стандартизированные сообщения
Помимо использования кодов состояния HTTP, которые указывают на результат запроса, всегда используйте стандартизированные ответы для аналогичных конечных точек. Пользователи могут всегда рассчитывать на одинаковую структуру и действовать соответственно. Это также относится к статусу, указывающему на выполнение запроса, и сообщениях об ошибках. В случае выборки коллекций придерживайтесь определенного формата, независимо от того, включает ли тело ответа массив данных, подобный этому:
[
{
bookId: 1,
name: "The Republic"
},
{
bookId: 2,
name: "Animal Farm"
}
]
или вот такой комбинированный ответ:
{
"data": [
{
"bookId": 1,
"name": "The Republic"
},
{
"bookId": 2,
"name": "Animal Farm"
}
],
"totalDocs": 200,
"nextPageId": 3
}
Здесь рекомендация заключается в том, чтобы быть последовательным независимо от того, какой подход вы выберете для этого. Аналогичное поведение должно быть реализовано при извлечении объекта, а также при создании и модификации ресурсов, которым обычно рекомендуется возвращать последний экземпляр объекта.
// Ответ после успешного вызова POST /books
{
"bookId": 3,
"name": "Brave New World"
}
Хоть это и никак не навредит, но все же излишнем будет включать универсальное сообщение, например, «Книга успешно создана», так как это уже следует из кода состояния HTTP.
И последнее, но не менее важное: при наличии стандартного формата ответа коды ошибок также важны (и даже более важные). Это сообщение должно включать информацию, которую клиент может использовать для представления ошибок конечному пользователю, а соответственно, это должно быть не общее предупреждение, такое как «то-то пошло не так», которого следует избегать, насколько это возможно. Вот пример:
{
"code": "book/not_found",
"message": "A book with the ID 6 could not be found"
}
Опять же, нет необходимости включать код состояния в содержимое ответа, но полезно определить набор кодов ошибок, таких как book/not_found, чтобы пользователь мог сопоставить их с разными строками и создать свое собственное сообщение об ошибке для конечного пользователя. В частности, для сред разработки или промежуточных сред может показаться правильным также включить стек ошибок в ответ с целью помочь в отладке ошибок. Но не включайте те, что находятся в промышленной эксплуатации, так как это создаст угрозу безопасности, раскрывая незапланированную информацию.
5. Используйте разбиение на страницы, фильтрацию и сортировку при выборе коллекций записей
Как только будет создана конечная точка, которая возвращает список элементов, необходимо будет установить разбиение на страницы. Обычно коллекции со временем растут, поэтому важно всегда следить за тем, чтобы возвращалось ограниченное и контролируемое количество элементов. Справедливо будет позволить пользователям API выбирать, сколько объектов получить, но всегда полезно заранее определить число и установить для него максимум. Основная причина, почему нужно это сделать, заключается в том, что для возврата огромного массива данных потребуется очень много времени и большая пропускная способность.
Для реализации нумерации страниц есть два хорошо известных способа: skip/limit или keyset. Первый вариант обеспечивает более удобный для пользователя способ извлечения данных, но обычно он менее эффективен, так как базы данных сканируют множество документов для извлечения нужных записей. Мне больше нравится второй вариант. Разделения на страницы с помощью keyset получает идентификатор (id) в качестве ссылки для «вырезания» коллекции или таблицы с условием без сканирования записей.
Также API должны предоставлять фильтры и возможности сортировки, которые упрощают способы получения данных. Частью решения повышения производительности являются индексные базы данных, которые позволяют максимизировать производительность при помощи шаблонов доступа, которые применяются с фильтрами и параметрами сортировки.
При проектировании API эти свойства разбиения на страницы, фильтрации и сортировки определяются как параметры запроса в URL-адресе. Например, если вы хотим получить информацию о первых 10 книгах, принадлежащих к категории «роман», то наша конечная точка будет выглядеть вот так:
GET /books?limit=10&category=romance
6. PATCH вместо PUT
Маловероятно, что необходимо будет сразу полностью обновить всю запись, обычно есть конфиденциальные или полные записи, которые следует уберечь от манипуляций пользователя. Именно поэтому для выполнения частичных обновлений ресурса следует использовать PATCH, а вот PUT полностью меняет существующий ресурс. Они оба должны использовать тело запроса для передачи информации, подлежащей модификации. Разница лишь в том, что для PATCH это поля, а для запроса PUT – полный объект. Тем не менее, стоит отметить, что ничто не мешает нам использовать PUT для частичной модификации, нет никаких «ограничений на передачу по сети», которые бы это подтверждали. Это просто факт, которого стоит придерживаться.
7. Предоставьте более подробные ответы
Шаблоны доступа являются ключевыми при создании доступных ресурсов API и возвращаемых данных. Когда система растет, то и свойства записи также растут, но не всегда все эти свойства нужны клиентам для работы. Именно в таких ситуациях становится полезным предоставление возможности возвращать сокращенные или полные ответы для одной и той же конечной точки. Если пользователю нужны только некоторые поля, то упрощенный ответ помогает снизить расход трафика и потенциально сложность получения других вычисляемых полей.
Простой способ реализовать – предоставить дополнительный параметр запроса, чтобы включить или отключить предоставление более подробного ответа.
GET /books/:id
{
"bookId": 1,
"name": "The Republic"
}GET /books/:id?extended=true
{
"bookId": 1,
"name": "The Republic"
"tags": ["philosophy", "history", "Greece"],
"author": {
"id": 1,
"name": "Plato"
}
}
8. Обязанность конечной точки
Принцип единственной обязанности фокусируется на концепции удержания функции, метода или класса на одной обязанности, которую они выполняют хорошо. Мы можем сказать, что это наш API - хороший API, если он выполняет одну конкретную вещь и никогда не меняется. Это помогает пользователям лучше понять наш API и сделать его более предсказуемым, что облегчит общую интеграцию. Лучше всего расширить список доступных конечных точек, а не создавать очень сложные конечные точки, которые пытаются решить множество задач одновременно.
9. Предоставьте полную документацию по API
Пользователи вашего API должны понимать, как использовать доступные конечные точки и чего ожидать. Это возможно только при наличии хорошей и подробной документации. Обратите внимание на следующие аспекты, чтобы ваша документация была полной.
Доступные конечные точки с описанием их назначения
Права доступа, необходимые для выполнения конечной точки
Примеры вызовов и ответов
Сообщения о предполагаемых ошибках
Немаловажным является постоянное обновление документации после внесения изменений и дополнений в систему. Лучший способ для этого – сделать документацию по API неотъемлемой частью разработки. Двумя хорошо известными инструментами в данном вопросе являются Swagger и Postman – они доступны для большинства сред разработки API.
10. Используйте SSL для обеспечения безопасности и настройте CORS
Безопасность – еще одно очень важной свойство, которым должен обладать наш API. Настройка SSL путем установки действительного сертификата на сервер обеспечит безопасную связь с пользователями и предотвратит некоторые виды потенциальных атак.
CORS (Cross-origin resource sharing – Обмен ресурсами с запросом происхождения) – это функция безопасности браузера, которая ограничивает HTTP-запросы из различных источников, которые инициируются сценариями, запущенными в браузере. Если ресурсы вашего REST API получают непростые HTTP-запросы из разных источников, то вам нужно включить поддержку CORS для того, чтобы пользователи работали соответствующим образом.
Протокол CORS требует, чтобы браузер отправил предварительный запрос на сервер и дождался утверждения (или запрос учетных данных) с сервера перед отправкой фактического запроса. Запрос предварительной проверки отображается в API как HTTP-запрос, использующий метод OPTIONS (среди других заголовков). Значит, для поддержки CORS в ресурсе REST API необходимо реализовать метод OPTIONS, который будет отвечать на предварительный запрос, по крайней мере, со следующими заголовками ответа, предусмотренными стандартом Fetch:
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Allow-Origin
Какие значения назначать этим ключам, зависит от того, настолько открытым и гибким должен быть наш API. Мы можем назначить определённые методы и известные источники или использовать специальные символы, чтобы иметь открытые ограничения CORS.
11. Управление версиями API
В процессе разработки конечные точки начинают меняться и перестраиваться. Но мы должны, насколько это возможно, избегать внезапного изменения конечных точек для пользователя. Рекомендуется рассматривать API как ресурс с обратной совместимость, в котором новые и обновленные конечные точки должны быть доступны, но не должны влиять на предыдущие стандарты.
Вот где управление версиями API приходит на помощь – когда клиенты должны иметь возможность выбирать, к какой версии подключаться. Есть несколько способов описать управление версиями API:
Добавление нового заголовка x-version=v2
Наличие параметра запроса ?apiVersion=2
Версия как часть URL: /v2/books/:id
12. Кэшируйте данные для повышения производительности
Чтобы повысить производительность нашего API, полезно следить за данными, которые редко меняются и к которым часто обращаются. Для таких данных мы можем рассмотреть возможность использования базы данных в памяти или кэш-памяти, которая избавит от доступа к основной базе данных. Главная проблема здесь заключается в том, что данные могут устареть, поэтому следует решить вопрос с внедрением последней версии.
Использование кэшированных данных будет полезным для пользователей для загрузки конфигураций и каталогов информации, которые не предназначены для постоянного изменения в течение долгого времени. При использовании кэширования не забудьте включить Cache-Control в заголовки. Это поможет пользователям эффективно использовать систему кэширования.
13. Используйте даты в формате UTC
Сложно представить системы, которые в какой-то момент перестает работать из-за дат. На уровне данных важно быть логичным в том, как даты отображаются на клиентских приложениях. ISO 8601 – это международный стандартный формат данных для даты и времени. Данные должны быть в формате Z или UTC, для которых пользователи могут могли бы выбрать часовой пояс в случае, если такая дата должны отображаться при любых условиях. Вот пример того, как должны выглядеть даты:
{
"createdAt": "2022-03-08T19:15:08Z"
}
14. Конечная точка проверки работоспособности
Может произойти ситуация, когда наш API перестанет работать, и для его запуска потребуется время. При таких обстоятельствах клиенты хотят знать, что службы недоступны, и быть в курсе ситуации. Для этого предоставьте конечную точку (например, GET /health), которая бы определяла работоспособность API. Эта конечная точка может вызываться и другими приложениями, такими как балансировщики нагрузки. Можно продвинуться еще дальне и сообщать о периодах технического обслуживания или работоспособности частей API.
15. Разрешите аутентификацию по ключу API
Аутентификация с помощью ключей API даст возможность сторонним приложениям легко создавать интеграцию с нашим API. Эти ключи API следует передавать с помощью пользовательского заголовка HTTP (например, Api-Key или X-Api-Key). Ключи должны иметь дату окончания срока действия, и должна быть возможность их отозвать с целью признания недействительными по соображениям безопасности.
Еще в 2000 году до нашей эры, когда алгоритмы только были изобретены, их создатели, наверное, даже представить не могли, что их будут использовать для управления большими металлическими самоходными средствами передвижения, которые сейчас для нас больше известны как «автомобили». Но сейчас, когда мы с вами живем в 21 веке, мы используем алгоритмы для управления многими аспектами нашей жизни – от искусственного интеллекта до криптовалюты и входа в обычные онлайн-сервисы.
Так что, если вы планируете искать работу, связанную с алгоритмами, то вы открываете для себя очень актуальную область с большим количеством возможностей. А теперь пришло время подготовиться к тому, чтобы произвести впечатление! Мы подготовили для вас 15 вопросов по алгоритмам, которые помогут вам подготовиться к собеседованию.
Читайте дальше, чтобы узнать о самых распространенных вопросах об алгоритмах, а также ответы на них и о том, как усовершенствовать свои навыки, чтобы подготовиться к собеседованию.
Что такое алгоритм?
Несмотря на то, что этот вопрос – элементарный, если вам задают его, важно ответить на него уверенно и без лишних слов. Алгоритм представляет собой последовательность вычислительных шагов, которые принимают входные данные или несколько входных данных и преобразуют их в выходные данные. Алгоритм можно написать в разных формах, например, с помощью обычного русского языка или используя псевдокод.
После того, как вы дадите краткий ответ, как этот, вы можете углубиться в эту тему, если захотите. Лучше сделать это на каком-то примере.
Что такое быстрая сортировка?
Этот вопрос нужен для того, чтобы проверить, способны ли вы применять алгоритмы хотя бы на самом базовом уровне. Алгоритм быстрой сортировки подходит для быстрой сортировки запросов или списков. В его основе лежит так называемый метод «разделяй и властвуй», то есть он занимается перестановкой групп, каждая из которых является одной из трех частей списка элементов:
Опорный элемент, выбранный из массива
Элементы меньше опорного размещаются слева от него для формирования левого подмассива
Элементы больше опорного размещаются справа от него для формирования правого подмассива
В подмассивах также выбирается опорный элемент, а остальные значения сортируются относительного него аналогично. Процесс повторяется до тех пор, пока в подмассивах не останется только один элемент.
Временная сложность алгоритма:
Наилучший случай:
On log
n
. Значение опорного элемента близко к среднему значению всех сортируемых элементов.
Наихудший случай:
On2
. Значение опорного элемента – это либо наибольшее, либо наименьшее значение всех сортируемых элементов.
Средний случай:
On log
n
.
В чем заключается роль опорного элемента?
Это еще один вопрос из темы поверхностного погружения в основы алгоритмов. Вы можете ответить, сказав, что опорный элемент – это элемент, который алгоритм выбирает из массива или матрицы, с которыми мы работаем, и который будет служить первым элементом для вычислений.
Есть множество способов, как выбрать опорный элемент. Для массива опорным элементом может служить первый или последний элемент, выбранный из середины или случайным образом. В зависимости от алгоритма способ выбора опорного элемента может влиять на качество результата.
Что понимается под временной сложностью алгоритма?
Это еще одно базовое понятие, связанное с алгоритмами, и поэтому ваш ответ должен начинаться с краткого определения. Временная сложность алгоритма – это количество итераций, которые необходимы для его завершения, в зависимости от размера входных данных.
Объясните различные обозначения, которые используют, когда речь идет о временной сложности
Отвечая на этот и любые последующие вопросы, вы демонстрируете свои знания того, как работают алгоритмы, а также что вы знаете, как их можно изменить, чтобы достичь желаемого результата.
Обозначения могут помочь оценить эффективность алгоритма. Вот обозначения, которые вы используете для временной сложности:
Большая омега: это означает «больше или столько же» итераций. Это точная нижняя граница роста времени работы алгоритма. По сути это наилучший случай временной сложности.
Большое О: это означает «меньше или столько же» итераций. Это точная верхняя граница роста времени работы алгоритма. По сути это наихудший случай временной сложности.
Большая тета: это означает «столько же» итераций. Это одновременно и точная верхняя граница, и точная нижняя граница роста времени работы алгоритма.
Маленькое О: это означает «меньше чем» итераций. Это верхняя граница, которая не является асимптотически точной.
Маленькая омега: это означает «больше чем» итераций. Это нижняя граница, которая не является асимптотически точной.
Как работает бинарный поиск?
Бинарный поиск используется для поиска элемента в уже отсортированном массиве. Первым делом мы смотрим на элемент в середине массива. Если это и есть искомый элемент, то поиск завершен. В противном случае, если искомый элемент больше того, что мы выбрали, процедура поиска повторяется в верхней половине массива (то есть среди значений, которые больше выбранного нами). Если же он меньше, то процедура поиска выполняется в нижней половине массива (то есть среди значений, которые меньше выбранного нами).
Временная сложность алгоритма:
Наилучший случай:
O1
. Искомое значение - это первый выбранный средний элементом.
Наихудший случай:
Olog
n
. Мы нашли искомое значение на одном из последних шагов, или оно вовсе отсутствует.
Средний случай:
Olog
n
.
Что подразумевается под сортировкой кучей (пирамидальной сортировкой)?
Сортировка кучей, или пирамидальная сортировка, подразумевает сравнение элементов с помощью алгоритма сортировки. Входные данные делятся на отсортированную и неотсортированную части. То, что перемещается в отсортированную часть, зависит от того, работаете вы с невозрастающей или возрастающей кучей. Невозрастающая куча в корне имеет элемент с максимальным значением, а возрастающая – с минимальным. Когда вы используете пирамидальную сортировку на невозрастающей куче, то неотсортированная часть уменьшается, так как самый большой элемент перемещается в отсортированную часть. В случае с возрастающей кучей в отсортированную часть перемещается элемент с наименьшим значением.
В невозрастающей куче значение родительского узла всегда больше, чем значения дочерних узлов. Для того, чтобы отсортировать элементы невозрастающей кучи с помощью алгоритма пирамидальной сортировки, необходимо выполнить следующие шаги:
Заменить последний элемент кучи корневым узлом
Убрать последний элемент, который мы только что поместили, из кучи
Преобразовать теперь уже двоичную кучу обратно в невозрастающую
Повторять процесс, пока не закончатся элементы.
Временная сложность алгоритма:
Наилучший случай:
O (n log
n
)
.
Наихудший случай:
O (n log
n
)
.
Средний случай:
O (n log
n
)
.
Для чего используется список пропусков?
Список пропусков используется для структурирования данных. В его основе лежат связные списки. А для того, чтобы создавать уровни новых ссылок в исходном связном списке, он использует вероятности. Можно провести аналогию с сетью автобусных маршрутов. Есть автобусы, которые останавливаются на каждой остановке, а есть такие, которые останавливаются только на определенных. У последних остановок меньше, чем у обычных автобусов. Создание новых уровней в списке пропусков можно рассматривать как вот такие ускоренные маршруты с меньшим количеством остановок. Если вы можете получать более эффективный доступ к наиболее часто используемым узлам, то такие задачи, как вставки или удаление узлов, станут намного проще и быстрее. И это будет более эффективно, чем применение каких-то других алгоритмов.
Какие криптографические алгоритмы являются наиболее распространенными?
Этот вопрос может показаться чересчур сложным, потому что вам кажется, что вам нужно запомнить огромное количество информации, но если вы вдруг пропустите пару алгоритмов, то никто не будет вас за это наказывать. И к тому же существует огромное количество алгоритмов. Вот некоторые из них:
IDEA
Blowfish
CAST
LOKI
DES
GOST
3-way
Что такое алгоритм хеширования и как он используется?
Вам захочется устроиться поудобнее, отвечая на этот вопрос, ведь хеш-алгоритмы сейчас очень популярны, так как используются в криптографии. Алгоритм хеширования ссылается на хеш-функцию, которая берет строку и преобразует ее в строку фиксированной длины, и не важно, какой длины она была изначально. Вы можете использовать алгоритм хеширования для самых разных целей – от криптовалюты до паролей и ряда других инструментов проверки.
Какую роль играют алгоритмы в криптовалюте?
Если вы устраиваетесь на работу, связанную с криптовалютой, то этот вопрос может оказаться для вас не таким простым, особенно если вы умудрились заблудиться в трех соснах, отвечая на него. Один из способов, как ответить на этот вопрос – упомянуть, насколько сильно криптовалюты на основе блокчейна зависят от криптографии. Блоки или записи, составляющие блокчейн, защищены с помощью криптографических методов, таких как хеш-алгоритмы. Также есть алгоритмы, которые используют для генерации открытых и закрытых ключей и для «майнинга» криптовалют.
Как работает алгоритм шифрования?
Такого рода вопросы на собеседовании могут дать вам некоторую подсказку о том, для какой работы вам могут нанять. Алгоритм шифрования преобразует обычный текст в код, или зашифрованный текст. Для этого алгоритм использует ключи. Чем длиннее ключи, тем больше есть возможностей для создания зашифрованного текста.
Что такое алгоритм поразрядной сортировки?
Поразрядная сортировка может пригодиться при работе с базами данных, или если ваша должность предусматривает то, что вы должны быть готовы ответить на этот вопрос. Поразрядная сортировка – это алгоритм сортировки, который не сравнивает элементы, а распределяет их по «корзинам», основываясь на разрядах. Если есть элементы с более чем одной значащей цифрой, то распределение по «корзинам» повторяется для каждой цифры.
Что такое рекурсивный алгоритм?
Рекурсивный алгоритм опирается на способ решения, при котором сложная задача разбивается на более мелкие подзадачи. Это делается до тех пор, пока не получится достаточно простая задача, которую можно было бы легко решить. Одним из примеров алгоритма, который можно реализовать рекурсивно, является бинарный поиск.
Какие три закона должны выполняться для рекурсивных алгоритмов?
Такие вопросы на собеседовании могут быть продолжением вопроса «Что такое рекурсивный алгоритм?» Рекурсивный алгоритм должен следовать следующим законам:
У него должен быть нерекурсивный вариант реализации.
Он должен вызывать сам себя.
Его можно изменить и вернуть к нерекурсивному варианту.
Модуль конференций в FreePBX 13 используется для создания внутреннего номера , конференц – комнаты, при звонке на который пользователи могут общаться в режиме конференции. Помимо прямого набора, секретарь может осуществить трансфер пользователя напрямую в конференц – рум. Давайте разберемся с настройкой данного модуля в FreePBX 13
Пошаговое видео
Настройка
Перейдем к настройке. Откроем вкладку Applications -> Conferences. Нажимаем кнопку Add чтобы добавить новую комнату
Откроется настройка конференц – рума. Давайте разберемся подробнее с каждой из настроек:
Давайте разберемся с опциями настройки:
Conference Number - Данный номер используется для присоединения к конференции
Conference Name - Имя для данной конференц – комнаты. Имена необходимы для удобства администрирования. Например, комнату можно назвать Support или Managers
User PIN - Это необязательное поле. Если вы хотите обеспечить приватность для комнаты, то вы можете назначить ей пароль. При звонке на номер комнаты, у пользователя будет запрошен пароль для подключения, который он должен будет ввести на телефонном аппарате. Данный PIN должен отличаться от PIN`a администратора.
Admin PIN - При вводе данного пин – кода, пользователь будет идентифицирован как лидер в данной комнате
Join Message - Голосовое сообщение, которое будет проигрываться пользователю при подключении к данной комнате. Данные голосовые файлы настраиваются в разделе System Recordings
Leader Wait - Если данная опция отмечена, то конференция не начнется до того как не подключиться лидер комнаты (с PIN – кодом админа)
Talker Optimization - Данная опция позволяет глушить звук от пользователи, которые не говорят в данный момент. Это позволяет изолировать посторонние шумы на фоне говорящего.
Talker Detection - Если данная опция включена, то при начале разговора, Asterisk будет идентифицировать канал докладчика и передавать события в AMI.
Quiet Mode - Если данная опция включена, то пользователям не будут проигрываться звуковые сообщения при подключении и отключении от конференции.
User Count - Объявлять ли текущее количество пользователей в конференц – комнате при подключении нового пользователя.
User Join/Leave - Если данная опция активирована, то при подключении, система будет запрашивать имя пользователя (произнести его). Далее, после того как пользователь подключился, ему и прочим далее подключающимся пользователям будут озвучены имена участников данной комнаты.
Music on Hold - Играть ли музыку, когда в данной комнате только один пользователь.
Music on Hold Class - В данном пункте можно выбрать музыку, которая будет проигрываться для пользователей пока они буду ожидать начала конференции.
Allow Menu - Отправлять ли пользователя в Meetme меню (будет описано ниже) при нажатии `*`.
Record Conference - Записывать ли данную конференцию
Maximum Participants - Максимальное количество пользователей в данной комнате. Значение «0» в данном поле означает неограниченное количество пользователей.
Mute on Join - Если данная опция выбрана, то при подключении нового пользователя, у него будет отключена возможность говорить в комнату. ВАЖНО Если вы не являетесь лидером в данной комнате, то чтобы получить возможность вести разговора в данной конференц – комнате, вам необходимо включить доступ к меню MeetMe (опция Allow Menu), чтобы пользователь имел возможность включиться в беседу.
Прочие опции - Другие опции зависят от установленных на вашему Asterisk модулей. Например, вы сможете добавить вашу комнату конференции в систему управления звонками iSymphony.
По окончанию настройки, нажмите Submit, а затем Apply Config. Давайте разберемся, какое меню доступно для пользователя конференц комнаты при нажатии «*», если это разрешено опцией Allow Menu
Цифра на телефоне
Действие от лидера комнаты
Действие от обычного пользователя
1
Включить/выключить звук у себя
Включить/выключить звук у себя
2
Заблокировать/разблокировать конференцию
Недоступно
3
Удалить из конференции последнего подключившегося пользователя
Недоступно
4
Уменьшить громкость звука в конференции
Та же опция, применимая к собственным настройкам пользователя
5
Сбросить громкость на настройки по умолчанию
Та же опция, применимая к собственным настройкам пользователя
6
Увеличить громкость звука в конференции
Та же опция, применимая к собственным настройкам пользователя
7
Уменьшить громкость вещания (громкость от говорящего)
Та же опция, применимая к собственным настройкам пользователя
8
Покинуть меню
Та же опция, применимая к собственным настройкам пользователя
9
Увеличить громкость вещания (громкость от говорящего)
Та же опция, применимая к собственным настройкам пользователя
0
Позволяет администратору выключать/включать звук у всех пользователей конференции
Недоступно
*
Озвучить возможные опции в меню
Та же опция, применимая к собственным настройкам пользователя
#
Покинуть конференцию
Покинуть конференцию
Таким образом, мы разобрались как настраивать конференции в FreePBX13