По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Протоколы API, как и все в этом мире, активно развиваются. Многие компании, включая GraphQL, gRPC и Thrift, пользуются классическими API SOAP и REST. В списке этих API есть и JSON-RPC.
JSON-RPC, созданный для быстрой разработки многофункциональных сайтов, быстро стал лучшим другом разработчиков.
Давайте разберемся, что это такое, и в чем оно полезно специалистам по разработке приложений и API. Знакомство с JSON-RPC начинается с азов JSON. Так что первая глава данной статьи посвящена общей информации о JSON.
JSON – что это такое, и как оно работает
JSON – это легковесный формат обмена сообщениями, который подходит для более быстрой передачи данных. Именно поэтому он так активно используется в современной разработке.
JSON (JavaScript Object Notation, или нотация объектов JavaScript) производит многократную разбивку данных до тех пор, пока они не примут удобный для обработки вид. В основе JSON лежит JavaScript, поэтому просматривая элементы данных, вы не раз встретите строки, нулевые символы, объекты и бинарные переменные.
JSON разбивает сложные сопоставленные данные на управляемые структуры, облегчая обработку данных на многих языках программирования, и считается независимым от языка ресурсом. Его придумал Дуглас Крокфорд в 2000 году с целью упрощения взаимодействия между веб-приложениями и сервером.
Что такое JSON RPC?
JSON-RPC – это не что иное, как преемник JSON, повсеместно признанный протокол для удаленного вызова процедур (RPC - Remote Procedure Calls). Работая на уровне разработки, JSON-RPC запускает различную структуру данных, определяя задачи для приложений. Это сравнительно новый протокол с узкой областью применения.
Наборы команд, гибкость и сценарии развертывания – все работает с ограничениями. Но, тем не менее, разработчики видят в нем идеальный вариант для простой и быстрой разработки. В простых сценариях данные ограничения не являются помехой и побуждают разработчиков переходить с REST на JSON-RPC. Стоит также добавить, что:
JSON-RPC определяет сетевые ограничения, связанные с обработкой данных.
Легкая конструкция и быстрая обработка – все это подходит для инициации передачи данных с узлами Ethereum.
Будучи транспортно-независимым протоколом, JSON-RPC может использовать для взаимодействия сокеты и HTTP.
Это отличное решение для разработки решений на базе Ethereum с использованием блокчейн.
В настоящий момент предлагается 2 стандарта JSON-RPC: JSON-RPC 1.0 и JSON-RPC 2.0:
JSON-RPC 1.0 не хватает возможностей сразу по нескольким пунктам. Отсутствие названий параметров и пояснений к ошибкам вызывает куда больше проблем, чем кажется. Скорее уж, это метод для одноранговой передачи данных.
Обновленный JSON RPC 2.0 значительно доработали, заполнив ряд пробелов предыдущей версии. Версию 1.0. заменили клиент-серверной 2.0. Кроме того, в 2.0. появились транспортные зависимости.
Разумеется, со временем добавили именованные параметры. Поля урезали. Нет ID для уведомлений; в качестве ответа отправляется только результат/ошибка. В обновленной версии есть дополнительные расширения с информацией об ошибках.
Как пользоваться JSON RPC?
Главная функция протокола заключается в отправке клиентских запросов на сервер (при поддержке JSON-RPC). Здесь под клиентом мы подразумеваем общепринятые приложения, которые развертываются для получения запроса от удаленной системы на консолидированный метод.
Введенные параметры передаются удаленной системе в формате массива или объекта. В зависимости от используемой версии JSON-RPC, удаленная система будет отправлять в источник запроса разные итоговые значения.
Все веб-передачи через JSON-RPC унифицированы и сериализированы с помощью JSON. Запрос JSON-RPC – это вызов удаленного метода. Он состоит из 3 элементов:
Метод. Указывает на строку, которая будет запрашиваться при вызове метода. Существует набор зарезервированных имен с префиксом ‘rpc’ – они предназначаются для внутренних вызовов RPC.
Параметры. Второй элемент JSON-RPC (объект или массив) со значением параметра, который будет переноситься. Параметры не вызываются в каждом вызове.
ID. Целое или строковое число, которое регулярно используется для поддержания баланса между запросами и ответами. Если на запрос нет ответа, то ID автоматически удаляется.
В запросе JSON-RPC получатель обязан вернуться к проверенному ответу на каждый полученный запрос. Добавляются 3 компонента:
Результат – первая и важнейшая часть запроса, передающая данные, которые возвращает вызываемый метод. Его часто называют JSON-stat, и при ошибке он остается пустым.
Ошибка – второй компонент. Появляется, если в процессе вызова что-то идет не так. В ошибке отображаются код и сообщение.
ID ответа указывает на запрос, по которому приходит ответ. Если ответов не требуется, то JSON-RPC использует уведомление, в котором написано, что запрос был без ID. В версии 1.0 ID уведомление приходит пустым, а в версии 2.0. оно полностью отсутствует.
Плюсы от использования JSON-RPC
JSON-RPC – это довольно «умный» протокол, который предлагает своим клиентам множество плюсов:
Простая обработка
JSON-RPC намного проще, чем REST. Его легко понимают люди и машины. Здесь нет сложных команд и наборов данных, так что JSON-RPC идеально подходит для начинающих разработчиков. Этот протокол Unicode предлагает компактную командную строку. Кроме того, он способен обрабатывать данные с именованными фразами или отдельными ключевыми словами. Таким образом, JSON-RPC считается простым и понятным инструментом для работы.
Быстрое время разработки
С JSON-RPC не надо ничего придумывать. Все источники доступны и понятны. Такая простота сокращает время разработки и сроки выхода на рынок. Это самое подходящее решение для разработки приложений в сжатые сроки.
Качественный обмен информацией
JSON-RPC гарантирует своевременный, быстрый и точный обмен данными, поскольку может обрабатывать уведомления и несколько вызовов. Чтобы продолжить свою работу, ему не нужно ждать ответа от сервера или клиента. Если сделан запрос сообщения, то JSON-RPC гарантированно доставит его «адресату». Не важно, насколько сложные компоненты приложения входят в цепочку коммуникации, JSON-RPC обеспечит должный обмен информацией.
Улучшенная производительность API
С помощью JSON-RPC можно создавать API, которые не зависят от развертываемого протокола. Такая возможность крайне важна для улучшения производительности API, т.к. заменяет HTTP и TCP, а также снижает рабочую нагрузку.
Описание результатов
JSON-RPC выдает понятные результаты запроса, которые легко прочитать и обработать. Создание пакетных запросов, объяснение body в HTTP и передача параметров – все это гораздо проще реализовать через JSON-RPC.
Улучшенная передача
JSON-RPC – это очень удобный для передачи инструмент, ведь поддерживает такие платформы, как XMPP, WebSockets, SFTP, SSH и SCP. Данное разграничение позволяет разрабатывать быстрые, простые в отладке и удобные для пользователя API. Кроме того, этот протокол полностью отделяет запрошенный контент от используемого процесса передачи. А любые ошибки в запросах, данные и предупреждения передаются через полезную информацию запроса.
REST и JSON-RPC: что выбрать для разработки API?
Богатый выбор API-ресурсов – это всегда хорошо, но остановиться на каком-то одном варианте бывает не так просто. Ниже мы постараемся помочь разработчикам и объясним ключевые особенности популярных протоколов.
JSON-RPC подходит для начинающих разработчиков с ограниченным количеством ресурсов. JSON-RPC – это очень ограниченный в ресурсах протокол, который отлично выполняет свою функцию. Кроме того, если цель разработчика хоть как-то связана с технологией распределенных реестров, то единственным жизнеспособным решением станет именно JSON-RPC. С таким развертыванием не сможет справиться ни один другой протокол.
Для разработки приложений, использующих технологии распределенных реестров, требуется независимый от протокола API, и JSON-RPC отлично подходит. Он позволяет разработчикам создавать API, которые могут взаимодействовать друг с другом с помощью любого протокола.
Есть еще одна область, в которой JSON-RPC превосходит REST. В REST доступен ограниченный набор глаголов, что приводит к ошибкам при выполнении операции. При использовании REST необходимо подробно описать HTTP-метод, и на это тратится много времени. Кроме того, в REST доступны только CRUD-операции. Так что лучше отдавать предпочтение JSON-RPC.
Тем не менее JSON-RPC нельзя назвать универсальным решением для всего. Его проблема заключается во взаимозависимости. Клиенты должны быть тесно связаны с реализацией служб, поэтому вносить изменения в эту реализацию довольно сложно. При попытке изменить что-то, клиенты чаще всего ломаются.
REST решает такие задачи намного лучше. Например, API на базе REST мало того, что легко создаются, так еще и не отслеживают состояния. Этот протокол совместим с HTTP и предлагает огромное множество HTTP-библиотек. REST позволяет создавать гибкие API. Это идеальное решение для CRUD-операций.
Оба протокола имеют свои плюсы и минусы. Разработчикам необходимо принять взвешенное решение, исходя из главной цели разработки. Например, если разработчику нужны высокопроизводительные вычисления, то стоит остановиться на JSON-RPC.
Если требуется независимая разработка приложения с удобным интерфейсом, то смело выбирайте REST. Не стоит также забывать о безопасности API.
JSON-RPC, graphql, grpc
Два самых известных аналога JSON-RPC – это GraphQL и gRPC. GraphQL – это полностью адаптивная система. Она используется для точной локализации данных запроса и получения только необходимых запрашиваемых данных. Основная черта – ориентация на клиента. Сервер практически никак не участвует в веб-передаче. Клиент сам устанавливает правила для обработки запрошенных данных.
GraphQL относится к языкам запросов, а JSON-RPC относится к удаленному вызову процедур.
Еще есть gRPC – легковесный протокол с акцентом на производительность. Это обновленная версия RPC. В JSON-RPC серверы и клиенты договариваются о запрашиваемых данных, а архитектура не важна. А в gRPC, наоборот, запросы обрабатываются по готовой схеме. Этот протокол может выполняться в любой экосистеме.
JSON-RPC интегрируется с MQTT, Python и Kallithea. Для gRPC доступны такие ресурсы, как .NET, JavaScript, C++, Swift и многие другие.
Главные отличия между всеми решениями заключаются в открытости кода и удобстве для клиентов.
Поговорим про инструмент Cisco Unified Real-Time Monitoring Tool (RTMT) , который используется для мониторинга системы Cisco Unified Communications Manager (CUCM) в реальном времени.
Установка
Сначала нужно перейти в меню Cisco Unified CM Administration и выбрать вкладку Application → Plugins. Здесь нажимаем Find и среди результатов поиска находим строчку Cisco Unified CM Real-Time Monitoring Tool (Windows либо Linux в зависимости от системы) и нажимаем Download.
Далее запускаем скачанный файл, выбираем место установки, принимаем лицензионное соглашение и устанавливаем RTMT.
После этого открываем программу и в появившемся окне указываем IP адрес сервера и логин с паролем администратора. Номер порта указываем 8443, если он не менялся.
Слева находится две вкладки. Вкладка System отображает общие данные системы, предупреждения, сообщения syslog и позволяет собирать трейсы.
System → System Summary → System Summary - Показывает общую информацию о системе (Использование памяти, CPU, HDD, предупреждения);
System → Server → CPU and Memory - Использование памяти и CPU;
System → Server → Process - Показывает запущенные процессы и какие ресурсы они используют;
System → Server → Disk Usage - Использование дискового пространства;
System → Server → Critical Services - Показывает состояние сервисов;
System → Performance → Performance - Позволяет выбрать отображаемые счетчики производительности;
System → Performance → Performance Log Viewer - Просмотр логов производительности;
System → Tools → Alert Central - Системные ошибки и настройка оповещений;
System → Tools → Trace & Log Central - Просмотр трейсов и логов;
System → Tools → Job Status - Показывает выполняемых работ;
System → Tools → SysLog Viewer - Просмотр SysLog сообщений;
System → Tools → VLT - Информация о Voice Log Translator;
Вкладка Communications Manager показывает информацию о CUCM серверах, информацию о звонках и подключенных устройствах.
CallManager → CallManager Summary → CallManager Summary - Общая информация о CUCM;
CallManager → Call Process → Call Activity - Информация о звонках;
CallManager → Call Process → Gateway Activity - Информация о шлюзах;
CallManager → Call Process → Trunk Activity - Информация о транках;
CallManager → Call Process → SDL Queue - Информация о Signal Distribution Layer;
CallManager → Call Process → SIP Activity - Отображает SIP активность;
CallManager → Device → Device Summary - Информация о подключенных устройствах;
CallManager → Device → Device Search - Поиск подключенных устройств;
CallManager → Device → Phone Summary - Информация о телефонных аппаратах;
CallManager → Service → Cisco TFTP - Информация о TFTP сервере;
CallManager → Service → Heartbeat - Отображает Heartbeat статус системы;
CallManager → Service → Database Summary - Информация о базе данных;
CallManager →CTI → CTI Manager - Computer Telelphony Integration информация;
CallManager →CTI → CTI Search - Поиск CTI;
Сетевые пользователи часто сталкиваются с необходимостью наличия статического общедоступного IP-адреса, например, при настройке веб-сервера, лаборатории с доступом через Интернет или даже при настройке почтового сервера. В таких случаях приходиться либо покупать новый интернет-пакет, включающий общедоступные IP-адреса, либо покупать новый пул статических общедоступных адресов у провайдера.
Однако начиная с Сisco IOS 12.4 и далее на маршрутизаторах Cisco можно настроить протокол DDNS (Dynamic DNS), который позволяет обновлять запись DNS при изменении IP – адреса маршрутизатора-следовательно, требование к статическому IP-адреу смягчается.
На приведенной ниже диаграмме показано функционирование службы DDNS:
Ниже приведено краткое описание работы DDNS с Cisco IOS:
Для регистрации у провайдера DDNS необходимо создать учетную запись. Настройте Интернет-маршрутизатор Cisco для работы в качестве клиента DDNS. Поставщик DNS создает уникальное доменное имя, указывающее на текущий динамический IP-адрес на Интернет-маршрутизаторе Cisco.
При перезагрузке интернет-маршрутизатора или изменении динамического IP-адреса он получает новый IP-адрес от провайдера. Клиент DDNS уведомляет сервер DDNS, и запись DNS обновляется с новым общедоступным IP-адресом.
Когда Интернет-пользователь хочет получить доступ к «test.dyndns.org», он отправляет DNS-запрос.
DDNS отвечает на запрос DNS, предоставляя IP-адрес 100.100.100.1 Интернет-маршрутизатора.
Как только пользователь получает динамический общедоступный IP-адрес интернет-маршрутизатора (100.100.100.1), пользователь может связываться с интернет-маршрутизатором через его вновь назначенный IP-адрес.
Ниже приведена конфигурация маршрутизатора Cisco для поддержки службы DDNS.
Шаг № 1 - Включите поиск DNS и настройте сервер IP-имен
HQ# configure terminalHQ(config)# ip domain-lookup
HQ(config)# ip name-server 4.4.4.4
HQ(config)# ip name-server 8.8.8.8
Шаг № 2 - Затем определите метод обновления DDNS:
HQ(config)# ip ddns update method dyndns
Шаг № 3 - В этом сценарии мы будем использовать HTTP в качестве метода обновления в конфигурации, чтобы указать URL-адрес, который маршрутизатор будет использовать для связи с поставщиком DDNS с новым публичным динамическим IP - адресом при изменении.
HQ(DDNS-update-method)# HTTP add http://username:password@members.dyndns.org/nic/update?system=dyndns&hostname=<h>&myip=<a>
Шаг № 4 - Далее мы устанавливаем интервал обновления, чтобы гарантировать, что FQDN обновляется как можно чаще. Конфигурация параметров интервала обновляется до 1 дня, 0 часов, 0 минут и 0 секунд.
HQ(DDNS-HTTP)# interval maximum 1 0 0 0
Шаг № 5 - Наконец, установите FQDN, которое будет обновляться, и включите службу DDNS на общедоступном интерфейсе (в этом сценарии будет использоваться Dialer0):
HQ(DDNS-update-method)# interface dialer0
HQ(config-if)# ip ddns update hostname test.dyndns.org
HQ(config-if)# ip ddns update dyndns
Для отладки DDNS введите следующие команды
HQ#debug ip ddns update