Иногда случается так, что обозначающий какое-либо явление термин появляется намного позже самого явления. Application Programming Interfaces — как раз тот самый случай: API, вернее, некое функциональное подобие программных интерфейсов, возникло еще в первой половине 40-х годов XX века, когда о персональных компьютерах человечество даже не помышляло. Давайте вспомним, как зародились API, как они развивались, и что стало причиной их появления на свет.

Сороковые

На дворе стоял конец сороковых годов. Европа понемногу восстанавливалась после второй мировой войны, за океаном, в Америке, наступила эпоха бурного развития электроники и вычислительных машин, и Великобритания всеми силами старалась не отставать от бывшей колонии. В математической лаборатории Кембриджского университета группа британских ученых и инженеров под руководством Мориса Уилкса строила электронно-вычислительную машину EDSAC (Electronic Delay Storage Automatic Calculator) — компьютер, архитектура которого во многом была навеяна работами Джона фон Неймана. Разработка этой машины началась в 1947 году. Как и многие ее современницы, она использовала принцип хранимой в памяти программы. Логика ЭВМ была реализована с помощью элементной базы на вакуумных лампах, а память, как и в UNIVAC, работала на «линиях задержки» (delay line memory) — заполненных ртутью элементах, во время войны нашедших свое применение в конструкции радаров. В качестве устройства ввода EDSAC использовал перфоленту, а вместо устройства вывода — телетайп.


EDSAC

После завершения испытаний EDSAC полноценно заработал в мае 1949 года, и начал обслуживать потребности научных подразделений Кембриджского университета. Поскольку перфоленту приходилось экономить, сотрудники математической лаборатории создали для EDSAC целый набор стандартных подпрограмм, выполняющих различные вычислительные операции — таким образом, для решения определенных задач можно было использовать уже готовую перфоленту, включив записанный на ней код в другую программу. Со временем таких «стандартных подпрограмм» накопился целый шкаф, и Морис Уилкс вместе со своим коллегой Дэвидом Уилером создал для него специальную картотеку наподобие библиотечной — каждая карточка содержала краткое описание подпрограммы и ее назначение. Но не менее важной задачей было донести до программистов, как встроить эту подпрограмму в создаваемый ими проект, какие параметры она принимает на вход и какие значения выдает на выходе, как ее «вызывать» из основного приложения.


Так выглядела библиотека перфолент Уилкса

Уилкс с коллегами написал набор таких инструкций, позже превратившийся в книгу «Подготовка программ для электронного цифрового компьютера» (The Preparation of Programs for an Electronic Digital Computer). Эта работа, опубликованная сегодня в свободном доступе, и стала первой в истории полноценной спецификацией прикладных программных интерфейсов, а сам шкаф с катушками перфолент и каталогом подпрограмм — прообразом современных API.


Обложка книги The Preparation of Programs for an Electronic Digital Computer

Пятидесятые-шестидесятые

Свое дальнейшее развитие интерфейсы прикладного программирования получили с появлением и бурной эволюцией языков высокого уровня: этот этап можно отнести к концу пятидесятых — началу шестидесятых годов ХХ столетия. Именно тогда перед разработчиками все чаще стала возникать необходимость абстрагироваться от базовой реализации тех или иных функций в коде, а вместо этого использовать готовые подпрограммы или библиотеки, позволяющие взаимодействовать только с отдельными объектами. Речь шла прежде всего о математических и статистических расчетах, для которых ЭВМ в ту эпоху применялись наиболее широко.

Таким образом, программист получал возможность решать свои прикладные задачи без необходимости вникать в особенности архитектуры файловой системы, реализации ввода-вывода и взаимодействия различных модулей в каждом конкретном языке программирования или версии компилятора. И первым языком, в котором официально стал использоваться API (тогда он назывался Application Program Interface, без суффикса –ing), стал Fortran.

На этом языке было реализовано множество проектов, ориентированных на специалистов в различных областях, одним из которых стала программа для обработки компьютерной графики. Чтобы избавить пользователя от необходимости взаимодействовать с графической подсистемой ЭВМ напрямую, а также обеспечить переносимость программы с одного компьютера на другой и добиться ее одинаковой работы на разных дисплеях, создатели графического приложения написали набор библиотек, которые можно было определенным образом вызвать из основной программы. К библиотекам прилагалось подробное описание синтаксиса вызовов их функций, которые авторы — Айра Коттон и Фрэнк Грейторекс — свели в статью «Структуры данных и методы для удаленной компьютерной графики» (Data structures and techniques for remote computer graphics). А её, в свою очередь, представили на конференции, организованной Американской федерацией сообществ обработки информации (American Federation of Information Processing Societies, AFIPS) в 1968 году.

Именно в этом докладе впервые в истории прозвучал термин API применительно к программным интерфейсам, пока еще одного конкретного приложения. При желании вы можете ознакомиться со статьей вот здесь. Тогда же API впервые стали рассматриваться в качестве универсального средства обеспечения взаимосвязи между программной и аппаратной компонентами компьютерных систем, например, для передачи информации между мейнфреймами или трансляции данных в приложение с устройств ввода и обратно, из приложения на устройства вывода, — в качестве средства аппаратной абстракции.


Диаграмма 1978 года, предлагающая расширить идею API до общего интерфейса программирования, выходящего за рамки только прикладных программ

Семидесятые – восьмидесятые

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

Первым в архитектуре СУБД стал использовать API один из пионеров британских компьютерных технологий, выпускник того же Кембриджского университета, теоретик реляционных баз данных Кристофер Дейт. В 1974 году он опубликовал статью «Реляционный и сетевой подходы: Сравнение интерфейсов прикладного программирования» (The Relational and Network Approaches: Comparison of the Application Programming Interface), в которой подробно описал преимущества реляционного подхода в архитектуре баз данных и возможности API для этой модели. Позже разработанный им программный интерфейс стал частью стандарта архитектуры СУБД ANSI-SPARC. В рамках этого стандарта проектирования баз данных программные интерфейсы (API) описывались как отдельная сущность, наравне с интерфейсом запросов.


Кристофер Дейт

На протяжении семидесятых и первой половины восьмидесятых годов API в программных продуктах, компиляторах и системах управления базами данных развивались в нескольких параллельных направлениях. Так, собственным API обладали языки С и C++, возможности которых активно использовались в UNIX. Поскольку этот же период был отмечен стремительной эволюцией компьютерных сетей, разработчикам все чаще требовалось использовать ресурсы файловой системы, отдельных библиотек и баз данных, расположенных не на локальном компьютере, а на удаленной машине или сервере в сети. Все это привело в конечном итоге к тому, что разработчики научились комбинировать различные API, и их возможности постепенно вышли за пределы моделей «вызов библиотечной функции из основной программы» или «использование отдельных файлов в качестве подключаемых подпрограмм в приложении».

Эволюция программных интерфейсов стала причиной того, что они перестали рассматриваться исключительно в аспекте разработки ПО, но получили более широкое применение — в рамках использования возможностей прикладными программами сетевых протоколов и различных компонентов операционных систем. При этом ОС с одним из наиболее подробно задокументированных API стали системы семейства Microsoft Windows.

Девяностые

Вторая половина восьмидесятых стала эпохой бурного развития интернета, персональных компьютеров и операционных систем для них. Неизбежно возникла необходимость в стандартах, которые позволили бы программистам быстро создавать прикладной софт с использованием всех функциональных возможностей ОС без необходимости глубоко погружаться в архитектуру платформы. А одной из самых популярных операционных систем для персоналок в вначале девяностых стала Windows.

Базовый API был реализован еще в Windows 1.0, но поддерживал он чуть менее 450 вызовов функций. С выходом Windows 3.Х возможности API этой операционной системы постепенно росли, но второе дыхание WinAPI обрел только с переходом на 32-разрядную архитектуру и появлением Windows NT и Windows 95. API Win32 включал уже тысячи функций, а возникновение технологии удаленного вызова процедур еще шире раздвинуло границы возможностей интерфейсов прикладного программирования от Microsoft. Впрочем, RPC нашел применение и в других областях, например, в языке программирования Java.

Некоторые приложения Windows, в том числе, браузер Internet Explorer, обладали собственным API, что позволило предоставлять различные веб-службы для сторонних приложений, — это нашло широкое применение в архитектуре Windows 98. Кроме того, начиная с Windows 95 Microsoft внедрила многокомпонентный API, разные модули которого предназначались для решения различного набора прикладных задач, например, Windows Multimedia API, API сетевых служб (Network Services), Graphics Device Interface, и т. д.


Карл Маламуд

Еще в 1990 году американский инженер, айтишник и писатель Карл Маламуд определил API как «набор сервисов, доступных программисту для выполнения определенных задач». Иными словами, само понятие API к тому моменту уже вышло за рамки собственно разработки ПО и архитектуры операционных систем, то есть, за рамки «программных интерфейсов» как таковых. Тогда же появились первые официальные стандарты, описывающие различные реализации API.

В октябре 1991 года была разработана общая архитектура брокера объектных запросов (Common Object Request Broker Architecture, CORBA), предложенная консорциумом OMG. Она предназначалась для авторов приложений, работающих под разными операционными системами. При этом такие приложения могут быть написаны на разных языках программирования, и даже работать на разных аппаратных платформах — стандарт предоставляет API для их полноценного взаимодействия таким образом, словно они находятся в адресном пространстве одного процесса. Фактически CORBA стала технологическим стандартом написания распределённых приложений, который определяет интерфейсы взаимодействия объектов с внешним миром.

В 1993 Microsoft представила стандарт Component Object Model (COM), предназначенный для создания объектов межпроцессного взаимодействия в различных языках программирования. Этот стандарт предоставляет разработчикам способ описания независимых от языка программирования объектов, которые можно использовать в различных средах — в том числе, отличных от той, в которой они были созданы изначально. На данном API базируются многие другие стандарты и технологии Microsoft, в том числе, OLE, ActiveX, COM+, DirectX, UMDF, Windows Runtime.

Дальнейшим развитием технологии стало появление в 1996 году запатентованной Microsoft Объектной модели распределенных компонентов (DCOM) — это технология предназначена для связи между программными компонентами на сетевых компьютерах и в распределенных системах. Одним из факторов, повлиявших на развитие DCOM, стало повсеместное использование RPC. В течение некоторого времени стандарты CORBA и DCOM конкурировали друг с другом. Считалось, что один из них станет стандартом API для распределенных приложений в интернете, но и у того, и у другого возникли сложности в связи с распространением в сети брандмауэров. Эпоха веб-приложений породила новые инструменты, которые постепенно вытеснили своих предшественников.

Новый век

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


Рой Филдинг

Один из авторов протокола HTTP Рой Томас Филдинг в 2000 году защитил диссертацию на тему «Архитектурные стили и проектирование сетевых программных архитектур» (Architectural Styles and the Design of Network-based Software Architectures), в которой подробно описал идею передачи репрезентативного состояния (REST). В рамках своей работы Филдинг предложил модель «сетевого интерфейса прикладного программирования» в противовес существовавшей ранее модели «библиотечно-ориентированного интерфейса API». Свою концепцию он назвал «WebAPI», а вскоре появились первые ее реализации на основе XML и JSON.

Со временем были созданы различные фреймворки для разработки веб-приложений, реализующие те или иные версии WebAPI, но большинство из них так или иначе опирается на предложенную Филдингом модель REST. Этот инструментарий активно развивается и сегодня, более того, под самим термином «API» в последние годы все чаще понимается именно WebAPI и различные реализации механизма передачи данных в веб-приложениях и облачной инфраструктуре.

Дальнейшим шагом в эволюции облачных технологий стал рост популярности микросервисных архитектур, реализующих веб-приложения в виде набора независимых и масштабируемых сервисов. В качестве дополнения к такому подходу возникла концепция микрофронтэндов — представление единого фрондэнда веб-приложения в виде набора независимо разрабатываемых и обновляемых компонент. Такая архитектура по умолчанию требует наличия полнофункционального WebAPI для сохранения связанности.

Сегодня API — это объемное понятие, охватывающее разработку приложений, архитектуру операционных систем, библиотеки и фреймворки, а также различные реализации WebAPI, применяемые в архитектуре веб-приложений и микросервисов. Разработка API для веб-приложений стала отдельной технологией, для которой в 2012 году специалисты из Facebook создали язык запросов и обработки данных GraphQL. Публичный релиз этого продукта состоялся в 2015-м. GraphQL — технология с открытым исходным кодом, позволяющая конструировать запросы данных с серовера и обрабатывать их на стороне клиента. Сами создатели технологии называют GraphQL «языком для WebAPI».

Комплекс технологий, которые сегодня называют общим термином «API», позволяет компаниям и разработчикам максимально эффективно использовать весь доступный им инструментарий для организации беспрепятственного обмена данными между компонентами приложений и интеграции этих приложений с различными публичными сервисами. Появившись в 40-х годах, «шкаф с перфолентами» прошел долгий путь до современных облачных технологий, и этот путь еще не окончен. Наш мир с каждым днем становится все более цифровым и взаимосвязанным, поэтому важность стандартов взаимодействия и обмена данными в будущем будет только возрастать.

Источники

API, EDSAC, Delay Line Memory: ртутная память UNIVAC I, Short history of API | From cabinet to big BOOM, The History and Evolution of APIs, Christopher J. Date, American Federation of Information Processing Societies, Roy Fielding, ANSI-SPARC Architecture, Carl Malamud, Windows API, Common Object Request Broker Architecture, Component Object Model.