Інтерфейс прикладного програмування

Інтерфейс прикладного програмування АРІ (application program interface) – призначений для використання прикладними програмами системних ресурсів ОС і функцій, які ОС реалізуються.

АРІ – описує сукупність функцій і процедур, які належать ядру або надбудовам ОС. Тобто АРІ – це набір функцій, які надаються системою програмування розробнику прикладної програми і які орієнтовані на організацію взаємодії результуючої прикладної програми із сукупністю програмних та апаратних засобів, в оточенні яких виконується результуюча програма. Сама результуюча програма породжується системою програмування, ґрунтуючись на коді вихідної програми, створеної програмістом, а також об’єктних модулів і бібліотек, які входять до складу системи програмування.

АРІ використовується не тільки прикладними, а також і системними програмами як в складі ОС, так і в складі системи програмування.

Функції АРІ дозволяють розробнику будувати результуючу прикладну програму таким чином, щоби використати засоби обчислювальної системи для виконання типових операцій. При цьому розробник програми не повинен створювати вихідний код для виконання цих операцій.

Програмний інтерфейс АРІ включає в себе не тільки самі функції, але і домовленості про їх використання, які регламентуються ОС, архітектурою обчислювальної системи і системою.

Існує декілька варіантів реалізації АРІ:

1. Реалізація на рівні ОС.

2. Реалізація на рівні системи програмування.

3. Реалізація на рівні зовнішньої бібліотеки процедур і функцій.

В кожному з цих варіантів розробнику надаються засоби для підключення функцій АРІ до вихідного коду програми і організації їх викликів. Об’єктний код функцій АРІ підключається до результуючої програми компонувальником при необхідності.

Варіанти реалізації api

Реалізація на рівні ОС

За виконання функцій АРІ відповідальність несе ОС. Об’єктний код, який виконує функції, або безпосередньо входить до складу ОС (або навіть ядра ОС), або входить до складу бібліотек, які динамічно завантажуються, і які розроблені для даної ОС. Система програмування відповідає тільки за організацію інтерфейсу для виклику цього коду.

В цьому варіанті результуюча програма звертається безпосередньо до ОС. Тому досягається найбільша ефективність виконання функцій АРІ у порівнянні з усіма іншими варіантами реалізації АРІ.

Недолік: відсутність можливості переносу не тільки коду результуючої програми, але і коду вихідної програми. Програма, створена для одної архітектури обчислювальної системи, не зможе виконуватись на обчислювальній системі іншої архітектури навіть після того, якщо її об’єктний код буде повністю перебудовано.

Частіше за все система програмування не зможе виконати перебудову вихідного коду для нової архітектури обчислювальної системи.

Можна уніфікувати функції АРІ в різних ОС. Але є корпоративні інтереси.

Приклад: Для ОС Microsoft Windows – WinAPI.

Але навіть всередині цього корпоративного АРІ існує певна невідповідність, яка дещо обмежує переносимість програм між різними ОС типу Windows.

Приклад: АРІ – набір сервісних функцій ОС для MS-DOS, який реалізовано у вигляді набору підпрограм обслуговування програмних переривань.

Реалізація на рівні системи програмування

В цьому випадку функції АРІ надаються користувачу у вигляді бібліотеки функцій відповідної мови програмування. Система програмування надає користувачу бібліотеку відповідної мови програмування і забезпечує підключення до відповідної програми об’єктного коду, що відповідає за виконання цих функцій.

Ефективність АРІ буде нижче, ніж у попередньому варіанті. Це тому, що для виконання багатьох функцій АРІ бібліотека мови програмування повинна все одно виконати звертання до функцій ОС.

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

Але є нестандартні бібліотеки.

Реалізація на рівні зовнішньої бібліотеки

У цьому варіанті функції АРІ надаються користувачу у вигляді бібліотеки процедур і функцій, яка може бути створена стороннім розробником.

Система програмування відповідала тільки за те, щоби підключити об’єктний код бібліотеки до результуючої програми, причому зовнішня бібліотека може бути і такою, що динамічно завантажується (тобто завантажується під час виконання програми).

З точки зору ефективності цей метод найгірший, оскільки зовнішня бібліотека звертається як до функцій ОС, так і до функцій мови програмування.

З точки зору переносимості, то тут тільки одна вимога – зовнішня бібліотека, яка використовується, повинна бути допустимою в довільній з архітектур обчислювальних систем, на які орієнтована прикладна програма. Це можливо, якщо бібліотека відповідає деякому прийнятому стандарту, а система програмування підтримує цей стандарт.

Бібліотека графічного інтерфейсу XLib підтримує стандарт графічного середовища XWindow:

MFC (Microsoft foundation classes) (OC Windows);

VCL (Visual controls library), „Borland”;

CLX, „Borland” (OC Linux, OC Windows).

Як правило АРІ не стандартизовані. В кожному конкретному випадку набір викликів АРІ визначається, перш за все, архітектурою ОС та її призначенням.

Робляться спроби стандартизувати деякий базовий набір функцій, оскільки це суттєво полегшує перенесення програм з одної ОС на іншу.

Приклад: стандарт POSIX. В ньому перераховано великий набір функцій, їх параметрів та значень, що повертаються. Стандартизуються не тільки звертання до АРІ, але і файлова система, організація доступу до зовнішніх пристроїв, набір системних команд.

Приклад: Внутрішній корпоративний стандарт Microsoft, WinAPI.

Win16, Win32_S, Win32, WinCE. З точки зору WinAPI, базова задача – вікно. Тобто він орієнтований на роботу в графічному середовищі.