Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

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



План:


Введення

Інтерфейс програмування додатків (іноді інтерфейс прикладного програмування) ( англ. application programming interface, API [Ей-пі-ай]) [1] - набір готових класів, процедур, функцій, структур і констант, що надаються додатком (бібліотекою, сервісом) для використання у зовнішніх програмних продуктах. Використовується програмістами для написання всіляких програм.


1. API як засіб інтеграції програм

API визначає функціональність, яку надає програма (модуль, бібліотека), при цьому API дозволяє абстрагуватися від того, як саме ця функціональність реалізована.

Якщо програму (модуль, бібліотеку) розглядати як чорний ящик, то API - це безліч "ручок", які доступні користувачеві даного ящика, які він може крутити і смикати.

Програмні компоненти взаємодіють один з одним за допомогою API. При цьому зазвичай компоненти утворюють ієрархію - високорівневі компоненти використовують API низькорівневих компонентів, а ті, в свою чергу, використовують API ще більш низькорівневих компонентів.

За таким принципом побудовані протоколи передачі даних по Internet. Стандартний стек протоколів ( мережева модель OSI) містить 7 рівнів (від фізичного рівня передачі біт до рівня протоколів програм, подібних протоколами HTTP і IMAP). Кожен рівень користується функціональністю попереднього рівня передачі даних і, в свою чергу, надає потрібну функціональність наступного рівня.

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

API бібліотеки функцій і класів включає в себе опис сигнатур і семантики функцій.


1.1. Сигнатура функції

Сигнатура функції - частина загального оголошення функції, що дозволяє засобам трансляції ідентифікувати функцію серед інших. У різних мовах програмування існують різні уявлення про сигнатурі функції, що також тісно пов'язане з можливостями перевантаження функції в цих мовах.

Іноді розрізняють сигнатуру виклику і сигнатуру реалізації функції. Сигнатура виклику зазвичай складається за синтаксичної конструкції виклику функції з урахуванням сигнатури області видимості даної функції, імені функції, послідовності фактичних типів аргументів у виклику і тип результату. У сигнатурі реалізації зазвичай беруть участь деякі елементи з синтаксичної конструкції оголошення функції: специфікатор області видимості функції, її ім'я і послідовність формальних типів аргументів.

Наприклад, в мові програмування С + + проста функція однозначно розпізнається компілятором по її імені і послідовності типів її аргументів, що складає сигнатуру функції в цій мові. Якщо функція є методом деякого класу, то в сигнатурі буде брати участь і ім'я класу.

В мовою програмування Java сигнатуру методу складає його ім'я і послідовність типів параметрів; тип значення в сигнатурі не бере участь.


1.2. Семантика функції

Семантика функції - це опис того, що дана функція робить. Семантика функції включає в себе опис того, що є результатом обчислення функції, як і від чого цей результат залежить. Зазвичай результат виконання залежить тільки від значень аргументів функції, але в деяких модулях є поняття стану. Тоді результат функції може залежати від цього стану, і, крім того, результатом може стати зміна стану. Логіка цих залежностей і змін відноситься до семантиці функції. Повним описом семантики функцій є виконуваний код функції або математичне визначення функції.


2. API операційних систем. Проблеми, пов'язані з різноманіттям API

Практично всі операційні системи ( Unix, Windows, Mac OS, і т. д.) мають API, за допомогою якого програмісти можуть створювати додатки для цієї операційної системи. Головний API операційних систем - це безліч системних викликів.

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

З іншого боку, відмінності в API різних операційних систем істотно ускладнюють перенесення додатків між платформами. Існують різні методи обходу цієї складності - написання "проміжних" API (API графічних інтерфейсів Qt, Gtk, і т. п.), написання бібліотек, які відображають системні виклики однієї ОС в системні виклики інший ОС (такі середовища виконання, як Wine, cygwin, і т. п.), введення стандартів кодування в мовах програмування (наприклад, стандартна бібліотека мови C), написання різних мов, що реалізуються на різних платформах ( sh, python, perl, php, tcl, Java, і т. д.).

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

Наприклад: для того щоб побачити в браузері рядок "Hello, world!", достатньо лише створити HTML -документ з мінімальним заголовком і найпростішим тілом, що містить цей рядок. Що станеться, коли браузер відкриє цей документ ? Програма-браузер передасть ім'я файлу (або вже відкритий дескриптор файлу) бібліотеці, обробній HTML-документи, та, в свою чергу, за допомогою API операційної системи прочитає цей файл і розбереться в його будові, потім послідовно викличе через API бібліотеки стандартних графічних примітивів операції типу "очистити віконце", "написати обраним шрифтом "Hello, world!". Під час виконання цих операцій бібліотека графічних примітивів звернеться до бібліотеки віконного інтерфейсу з відповідними запитами, вже ця бібліотека звернеться до API операційної системи, щоб записати дані в буфер відеокарти.

При цьому практично на кожному з рівнів реально існує кілька можливих альтернативних API. Наприклад: ми могли б писати вихідний документ не на HTML, а на LaTeX, для відображення могли б використовувати будь-який браузер. Різні браузери, взагалі кажучи, використовують різні HTML-бібліотеки, і, крім того, все це може бути (взагалі кажучи) зібрано з використанням різних бібліотек примітивів і на різних операційних системах.

Основними труднощами існуючих багаторівневих систем API, таким чином, є:

  • Складність портування програмного коду з однієї системи API на іншу (наприклад, при зміні ОС);
  • Втрата функціональності при переході з більш низького рівня на вищий. Грубо кажучи, кожен "шар" API створюється для полегшення виконання деякого стандартного набору операцій. Але при цьому реально не може, або стає принципово неможливим виконання деяких інших операцій, які надає більш низький рівень API.

3. Найбільш відомі API

3.1. API операційних систем

3.2. API графічних інтерфейсів

3.3. API звукових інтерфейсів

3.4. API аутентифікаційних систем

3.5. Web API

Використовується в веб-розробки, як правило, певний набір HTTP-запитів, а також визначення структури HTTP-відповідей, для вираження яких використовують XML або JSON формати. "Web API" є практично синонімом для веб-служби, хоча останнім часом за рахунок тенденції Web 2.0 здійснений перехід від SOAP до REST типу комунікації. Веб-інтерфейси, що забезпечують поєднання декількох сервісів в нових програмах, відомі як гібридні.

Приклади: Вікіпедія API


Примітки

  1. Часто неправильно вимовляють як [апі]. Використовується і укорочений варіант перекладу - інтерфейс програми.
Операційна система
Ядро
Управління
процесом
Управління
пам'яттю
Приклади
Інше

Цей текст може містити помилки.

Схожі роботи | скачати

Схожі роботи:
Інтерфейс (об'єктно-орієнтоване програмування)
Інтерфейс
Веб-інтерфейс
Інтерфейс користувача
Віконний інтерфейс
Нейрокомпьютерной інтерфейс
MME (інтерфейс)
Масштабований інтерфейс користувача
Сокет (програмний інтерфейс)
© Усі права захищені
написати до нас
Рейтинг@Mail.ru