Приложно-програмният интерфейс (, API) е интерфейсът на изходния код, който операционната система или нейните библиотеки от ниско ниво предлагат за поддръжката на заявките от приложния софтуер или компютърните програми.
Образно казано, приложно-програмният интерфейс предоставя един по-абстрактен и опростен план за разработчика на приложения, който би му спестил изучаването на няколко различни слоя от Операционната или софтуерната система зад интерфейса. По този начин се достига ефективност и бързина при адаптирането на нови софтуерни технологии.
В миналото терминът се е използвал за обозначението на интерфейса между две програми.
Употреба API в процедурните езици В повечето процедурни езици приложно-програмния интерфейс (API) указва набор от функции или програми, които изпълняват определена задача или имат възможност за взаимодействие с определен софтуер. Тази спецификация е представена в разбираем за човека хартиен (при хартиените книги) или електронен формат (при електронните книги). Например математическото API в Unix системите указва начина, по който да се използват математическите функции, които са включени в математическата библиотека. Сред тези функции има функция, наречена sqrt(), която се използва за изчисляването на корен квадратен от дадено число. Unix командата man 3 sqrt представя сигнатурата на функцията sqrt в следния формат: SYNOPSIS #include <math.h> double sqrt(double X); float sqrtf(float X); DESCRIPTION sqrt изчислява корен квадратен от аргумента. ... RETURNS При успешно изчисляване като резултат се връща корен квадратен от аргумента...
Това описание означава, че функцията sqrt() връща като резултат корен квадратен от положително дробно число друго дробно число.
Оттук следва, че в този случай API-то може да бъде разглеждано като колекция от вмъкнати файлове, използвани от дадена програма, написана на езика C, правеща препратка към тази библиотека и нейното описание на разбираем човешки език, предоставени от страниците за упътване.
По този начин други езици също имат процедурни библиотеки. Например езика Perl е посветил API за същата математическа задача с вградена документация, която е достъпна чрез помощната програма perldoc: $ perldoc -f sqrt sqrt EXPR sqrt #Връща корен квадратен от EXPR. Ако EXPR е пропуснато, връща #корен квадратен от $_. Работи само върху неотрицателни операнди, освен ако #не сте заредили стандартния Math::Complex модул.
API в обектно-ориентираните езици В своята най-проста форма обектното API представлява описание на начина, по който обектите работят в даден обектно-ориентиран език – най-често е представян като набор от класове със съответен списък на методите в класа.
Например в езика Java, ако трябва да се използва класа Scanner (клас, който чете данните, въведени от потребителя в текстова програма), е необходимо да се вмъкне и библиотеката java.util.Scanner, като по този начин обектите от тип Scanner може да се използват, като се извика някой от методите на класа:
import java.util.Scanner;
public class Test { public static void main(String[] args) { System.out.println("Въведи твоето името:"); Scanner inputScanner = new Scanner(System.in); String name = inputScanner.nextLine(); System.out.println("Твоето име е " + name + "."); inputScanner.close();
В горния пример методите nextLine() и close() са част от API за класа Scanner и следователно са описани в документацията на това API, например:
Като цяло, в обектно-ориентираните езици едно API обикновено включва описание на класове с група от поведения, свързани с тези класове. Тази абстрактна концепция е свързана с истинската функционалност на класовете, които се изпълняват по отношение на методите на класа (или по-общо казано от всички негови публични компоненти, като публичните методи, а също и всеки вътрешен компонент, който е направен публичен, като полета, константи, вмъкнати обекти, енумерации и др.).
API в този случай може да се разглежда като съвкупност от всички методи, които са направени публични от класовете (наричани често интерфейси). Това означава, че API определя методите, с които някой взаимодейства с обектите, които произлизат от дефинициите на класовете.
По-общо казано API може да бъде разглеждано като съвкупност от всички видове обекти, които могат да произлизат от дефинициите на класовете и свързаните с тях възможни поведения. Употребата на API се постига с помощта на публични методи, но в тази интерпретация, методите се разглеждат като технически детайл на начина по който е имплементирано поведението им.
Например, клас, представляващ Stack може просто да представи публично два метода – push() (добавя нов елемент към стека) и pop() (премахва последния елемент, който се намира най-отгоре в стека).
В този случай това API може да се обясни като два метода pop() и push(), или по-общо казано като идея, при която някой може да използва елемент от тип Stack, който имплементира (наследява) поведението на стека: една купчина, на която да се добавят или премахват нейните елементи, намиращи се най-отгоре в нея. Втората интерпретация изглежда по-подходяща в духа на обектното ориентиране.
Тази концепция може да бъде приложена до там, докъдето интерфейса на класа в едно API като цяло няма методи, а има само поведения, свързани с него. Например, API-тата на езиците Java и Lisp съдържат интерфейс с името Serializable, който е водещ интерфейс, изискващ всеки клас да го имплементира с поведението на класа serialized. Това не изисква имплементация на публичен метод, а изисква всеки клас, който имплементира този интерфейс да бъде на основата на представяне, което може да бъде записано по всяко време.
По същия начин поведението на обект в многонишкова среда не е задължително да се определя от конкретни методи, принадлежащи на имплементирания интерфейс, но все още принадлежащи и на API-то за обектите от този клас, и би трябвало да бъде описано в документацията.
В този смисъл, в обектно-ориентираните езици, едно API дефинира колекция от поведението на обекти, вероятно предизвикани от методите на класа.
В подобни езици, едно API се разпространява като библиотека. Например, библиотеките на езика Java включват набор от API-та, които се предоставят под формата на JDK, използвани от разработчиците да създават нови Java приложения. Едно JDK включва документацията на API-то в JavaDoc формат.
Количеството на документацията, свързана с едно API често е фактор, определящ неговия успех по отношение на лекотата на използване.
API библиотеки и софтуерни рамки Едно API често е свързвано със софтуерна библиотека: API-то описва и определя очакваното поведение, докато библиотеката е актуалната имплементация на този набор от правила. Едно API може да има множествена имплементация (или никаква – ако е абстрактно) под формата на различни библиотеки, които споделят един и същ програмен интерфейс.
Едно API може също да бъде свързано със софтуерна рамка: рамката може да бъде базирана на няколко библиотеки, имплементиращи няколко API-та, но за разлика от нормалното ползване на API-та, достъпа до поведението, което е вградено в рамката се осъществява чрез разширение на съдържанието му с нови класове, вмъкнати в самата библиотека. Освен цялостната програма за контрол на потока, може да бъде извън контрола на извикващия, и в ръцете на рамката чрез inversion of control или друг подобен механизъм.
API и протоколи Едно API също така може да бъде и имплементация на протокол.
Когато едно API имплементира даден протокол, то може да бъде базирано на прокси методи за отдалечени извиквания, които отдолу разчитат на комуникационния протокол. Ролята на едно API може скриването точно подробностите от транспортния протокол. Например RMI е API, което имплементира протокола JRMR или IIOP като RMI-IIOP.
Обикновено протоколите се споделят между различни технологии (система, която е базирана на дадени компютърни програмни езици в дадена операционна система) и обикновено позволяват различните технологии да обменят информация, имайки ролята на посредник между две различни среди. Следователно протокола може да бъде считан като отдалечено API, докато локалните API-та обикновено са специфични за дадена технология. Ето защо едно API, което е създадено за дадена технология, не може да бъде използвано в други езици, освен ако извикванията на функция не са вмъкнати в конкретни библиотеки за адаптация.
За да бъде възможно обменянето на информация между системите, които използват различни технологии, когато едно API имплементира протокол, то може да предвижда формат за съобщение на неутрален език, например SOAP използва XML като общ контейнер на съобщенията, които трябва да бъдат обменяни, като по същия начин и REST API може да използва двете XML и JSON.
API за обмяна на обекти и протоколи Едно обектно API може да предвижда специфичен формат за обмяна на обекти, който програмата може да използва локално в приложението, докато протокола за обмяна на обекти може да дефинира начина за трансфер на един и същ тип информация в съобщение, което е изпратено към отдалечена система.
Когато се обменят съобщения чрез протокол между две различни платформи, използвайки обекти от двете страни, обекта в програмния език може да бъде трансформиран в обект в отдалечения и различен език, например програма, която е написана на Java се обръща към услуга чрез SOAP или IIOP, написан на C#, като двете програми използват API-та за отдалечено извикване (всеки локално към машината, където те работят), за да обменят дистанционно информация, която двете конвертират от/към обект в локалната памет.
Вместо това когато подобен обект се обменя чрез API локално към една машина, то обекта се обменя ефективно в паметта, например чрез памет, предназначена за единствен процес, или между няколко процеса, използвайки споделена памет, сървърно приложение или други технологии за споделяне като tuple space.
Отдалечено API на обекти и протоколи Отдалеченото API за обекти е базирано на отдалечен протокол, като CORBA, който позволява извикване на отдалечен обектен метод. Извикване на метод, който е изпълнен локално върху прокси обект, извиква съответния метод върху отдалечение обект, използвайки отдалечен протокол, като изисква резултата да бъде използван локално като връщана стойност.
Когато отдалечението е на място, модификация на прокси обекта отговаря на модификация на отдалечение обект. Когато имаме само трансфер на обект, модификацията на локалното копие на обекта не е рефлектирано върху оригиналния обект, освен ако обекта не е изпратен към изпращаща система.
Споделяне на API-та и преизползване чрез виртуална машина Някои езици, като тези, които се изпълняват върху виртуална машина (например .NET CLI компилиращите езици в CLR-а, и JVM-компилиращите езици в Java виртуалната машина) могат да споделят API. В този случай виртуалната машина позволява взаимодействието между езиците, правещ абстрактен програмния език, използвайки междинен байт код и неговите езикови привързвания. В тези езици компилатора подготвя навременна компилация или преждевременна компилация, трансформирайки сорс кода, вероятно написан на няколко езика, в неговото независимо езиково байт код представяне.
Например чрез байт код представяне, програма, която е написана на езиците Groovy или Scala имат обектен модел, който е superset на този, който е на езика Java, така, че всяко API, което е представено чрез Java обект е достъпно чрез Groovy и Scala с еквивалентно извикване на обект, преведено в байт код.
От друга страна обектите от най-високо ниво, които не присъстват в Java като закривания. Тези обекти не могат да бъдат естествено представени в езика Java (Java 8 въведе концепцията за анонимна функция. Така, че за да даде възможност за много операции, closure е капсулирана в стандартен Java обект. В този случай извикването на closure е става с посредничещ метод, с името call(), който често се представя в closure обект, както е при Java.
Уеб API