API

Давайте на парсек поднимемся над нашей ежедневной рутиной и взглянем на сеть с расстояния. И тогда можно увидеть, что программную работу с сетевым оборудованием следует рассматривать как взаимодействие с удалённой системой (чем она и является). А уже много лет назад для этого придумали термин - API.

То есть, если мы хотим чего-то от этой системы, мы используем известный интерфейс, для которого описано, как и что мы должны сделать, чтобы добиться желаемого результата.

API - это широкий и абстрактный термин, сам по себе не говорящий ничего о схеме данных, о формате и протоколах взаимодействия - просто программный интерфейс приложения - не человеческий, а программный.

И под одним этим зонтичным термином скрываются совершенно разные виды:

• REST API

• GraphQL

• XML RPC

• Linux Kernel API

• SOAP

• CORBA

• PCI шины

• JSON RPC

• Android API

• И сотни других

  

  Хотя никто его так и не называл.

Одни из них, такие как REST, оперируют ресурсами и представляют набор операций над ними, в случае REST: CRUD - Create, Read, Update, Delete. То есть вы можете создать (Create) ресурс «билет на linkmeetup» и скачать (Read) его далее в любой момент. С REST мы уже разбирались как-то.

Другие виды API оперируют функциями, и позволяют на сервере запускать те или иные оговоренные программы. К последним относится класс API, который можно назвать RPC.

RPC - Remote Procedure Call

Этот термин родом из языков программирования. Ещё на рубеже 50-60-х годов языки вроде Fortran II и ALGOL ввели в обиход разработчиков процедуры (они же функции). С тех пор они везде - большинство языков - процедурные. Любое действие - это вызов процедуры - Procedure Call.

И когда-то эта процедура должна была находиться где-то в том же модуле или в соседних, но точно рядом и в том же окружении.

Но почему бы не слать вызов с параметрами на удалённую машину, где мы хотим что-то выполнить?

Например, мы могли бы по HTTP/FTP скачать несколько гигов данных sFlow с сервера и проанализировать их локально, а можем отправить сигнал на сервер, чтобы сложную статистику вычислил он сам и вернул результаты в ответе. Так вот второе - это удалённое исполнение кода.

Анналы истории говорят, что в в 1981 году Брюс Джей Нельсон, работая в Ксероксе, изобрёл концепцию и термин RPC - Remote Procedure Call.

RPC - удивительный клиент-серверный механизм, который позволяет запустить исполнение кода процедуры на другой машине так, словно бы он исполнялся локально. То есть разработчик просто привычным образом обращается к процедуре, не задумываясь о том, где и как она исполняется - главное, чтобы она вернула ответ.

А программа уже сама реализует взаимодействие с удалённой машиной.

Прелесть этого подхода в том, что он, во-первых, позволяет скрыть удалённый характер работы. А, во-вторых, на той, другой, стороне совершенно неважно, какая операционная система, архитектура, язык программирования и окружение - главное, чтобы они подчинялись одному протоколу.

Можно провести аналогию с TCP - не важно, какие операционные системы на хостах, желающих друг с другом общаться, - важно, чтобы они следовали спецификациям протокола TCP и его конкретной реализации - и тогда данные, отправленные одним хостом, будет возможно интерпретировать на другом.

Так в случае RPC, из-под винды в питоне, например, вы можете исполнить удалённую программу, написанную на Go, запущенную на линуксе. И никто вам не сможет помешать! (Кроме сетевиков)

Но что, по большому счёту, мы делаем, когда, зайдя по SSH, выполняем какую-то команду на коммутаторе или маршрутизаторе? Запускаем определённый код.

Например, сообщаем подсистеме BGP, что нужно теперь пробовать установить соединение с новым пиром.

Только представьте, как было бы восхитительно, если бы для вызова этого кода, не нужно было заходить на железку по SSH и вбивать команду?!

Взаимодействие между приложениями через RPC используется преимущественно в условиях, когда требуется обеспечить тесную связь между ними, когда они все формируют единую систему.

В то же время REST API наоборот требуется, когда компоненты должны быть достаточно изолированы и развиваться независимо.

Так REST обычно предоставляют внешним клиентам, B2B, смежным, но малосвязанным командам. Например, публикация постов в соц.сетях или агрегаторы авиабилетов при обращении к сервисам авиакомпаний. А RPC - там, где компоненты составляют часть чего-то большего, например, узлы банковской системы или микросервисные архитектуры.

В целом RPC - это концепция, не говорящая ничего о реализации.

Она постулирует, что на стороне клиента есть так называемый стаб (stub) - фрагмент кода, который реализует взаимодействие по RPC. Именно стабы делают для разработчика прозрачным вызов функции - из приложения вызывается этот стаб с набором параметров, а уже стаб делает удалённый вызов.

Ключевая часть RPC - спецификация - штука, которая на стороне сервера и клиента определяет, как работать с данными - как упаковать, как распаковать. Без участия человека, конечно же.

Язык, на котором пишется спецификация - IDL - Interface Definition Language.

Иными словами, на IDL пишется спецификация, на основе которой создаются и серверный интерфейс, и клиентский стаб. Это может быть, например, набор классов в питоне, имеющих функции для удалённого вызова, с которыми разработчик работает так, словно всё происходит локально - для клиента. И набор объектов Go - для сервера.

Наевшись с CLI и SNMP, сетевики придумали два протокола, которые используют под капотом RPC и при этом позволяют управлять сетевым железом:

• NETCONF
• gNMI (как фреймворк над gRPC)