Приложно-програмен интерфейс

14.06.2016

Приложно-програмният интерфейс (на английски: Application Programming Interface, API) e интерфейсът на изходния код, който операционната система или нейните библиотеки от ниско ниво предлагат за поддръжката на заявките от приложния софтуер или компютърните програми.

 

Образно казано, приложно-програмният интерфейс предоставя един по-абстрактен и опростен план за разработчика на приложения, който би му спестил изучаването на няколко различни слоя от операционната или софтуерната система зад интерфейса. По този начин се достига ефективност и бързина при адаптирането на нови софтуерни технологии.

 

По същество API-тата се делят на:

• Функционални
• По данни
• Обектно-ориентирани
• Протоколни

 

Функционалните програмни интерфейси разпознават само функции като средство за комуникация. При това почти винаги бива използвана така наречената handle концепция. При извикването на една функция бива върнат обратно handle. С помощта на този handle могат да бъдат извиквани други функции, докато не трябва отново да бъде затворен. BIOS-ът на един персонален компютър е най-старият програмен интерфейс от този тип.

 

При програмните интерфейси по данни, комуникацията се осъществява чрез извикването на стандартните команди open, read, write и close за обработването на файл системи. Ако дадени данни трябва да бъдат пратени на обект, то те биват написани с помощта на командата write. Ако дадени данни трябва да бъдат приети, то те биват прочетени с помощта на командата read.

Обектно-ориентираните програмни интерфейси използват указатели към интерфейси.

 

Протоколните програмни интерфейси са независими от операционната система и хардуера. За сметка на това, протоколът трябва винаги да бъде програмиран наново. За да се ограничат до минимум средствата използвани за това, протоколният програмен интерфейс може да бъде свързан например с функционален интерфейс. Два вида протокола биват различавани — такива, които са зависими от приложението (например SMTP) и общи (например SOAP).

 

Няколко принципа се използват за управление на процеса за изработване на API дизайн. Принципът на скриване на информация е следния - някой може да разглежда софтуера на модули, всеки от който има специфичен интерфейс. Интерфейсите крият детайлите за имплементация, така, че потребителите на модулите нямат нужда от това да разбират сложността на вътрешността на модулите. Тези интерфейси са API-та, и като резултат API-тата би трябвало да показват само тези детайли за модела, които клиентите трябва да знаят, за да използват модулите ефективно. Софтуерната архитектура е посветена на създаването и поддържането на софтуерни структури от най-високо ниво, нещо което обикновено включва и модули. Все пак доста решения, които са свързани със създаването на API-та не са архитектурни - такива като конвенциите за именуване, както и множеството детайли за начина по който са структурирани интерфейсите.

 

Тези детайли за начина, по който са структурирани интерфейсите, също като софтуерната архитектура, имат значително влияние върху качеството на софтуера.

 

Законът на Конуей казва, че структурата на системата неминуемо рефлектира върху структурата на организацията, която го е създала. Това предполага, че за да се разбере как е направен дизайна на API-тата в истинския сват, трябва да се разберат и структурите на софтуерните инженерни организации.

 

Едно API често е свързвано със софтуерна библиотека: API-то описва и определя очакваното поведение, докато библиотеката е актуалната имплементация на този набор от правила. Едно API може да има множествена имплементация (или никаква - ако е абстрактно) под формата на различни библиотеки, които споделят един и същ програмен интерфейс.

 

Едно API може също да бъде свързано със софтуерна рамка: рамката може да бъде базирана на няколко библиотеки, имплементиращи няколко API-та, но за разлика от нормалното ползване на API-та, достъпа до поведението, което е вградено в рамката се осъществява чрез разширение на съдържанието му с нови класове, вмъкнати в самата библиотека. Освен цялостната програма за контрол на потока, може да бъде извън контрола на извикващия, и в ръцете на рамката чрез inversion of control или друг подобен механизъм.

 

Едно API също така може да бъде и имплементация на протокол. Когато едно API имплементира даден протокол, то може да бъде базирано на прокси методи за отдалечени извиквания, които отдолу разчитат на комуникационния протокол. Ролята на едно API може скриването точно подробностите от транспортния протокол. Например RMI е API, което имплементира протокола JRMR или IIOP като RMI-IIOP.

 

Обикновено протоколите се споделят между различни технологии (система, която е базирана на дадени компютърни програмни езици в дадена операционна система) и обикновено позволяват различните технологии да обменят информация, имайки ролята на посредник между две различни среди. Следователно протокола може да бъде считан като отдалечено API, докато локалните API-та обикновено са специфични за дадена технология. Ето защо едно API, което е създадено за дадена технология, не може да бъде използвано в други езици, освен ако извикванията на функция не са вмъкнати в конкретни библиотеки за адаптация.

 

За да бъде възможно обменянето на информация между системите, които използват различни технологии, когато едно API имплементира протокол, то може да предвижда формат за съобщение на неутрален език, например SOAP използва XML като като общ контейнер на съобщенията, които трябва да бъдат обменяни, като по същия начин и REST API може да използва двете XML и JSON.

 

Едно обектно API може да предвижда специфичен формат за обмяна на обекти, който програмата може да използва локално в приложението, докато протокола за обмяна на обекти може да дефинира начина за трансфер на един и същ тип информация в съобщение, което е изпратено към отдалечена система.

 

Когато се обменят съобщения чрез протокол между две различни платформи, използвайки обекти от двете страни, обекта в програмния език може да бъде трансформиран в обект в отдалечения и различен език, например програма, която е написана на Java се обръща към услуга чрез SOAP или IIOP, написан на C#, като двете програми използват API-та за отдалечено извикване (всеки локално към машината, където те работят), за да обменят дистанционно информация, която двете конвертират от/към обект в локалната памет.

 

Вместо това когато подобен обект се обменя чрез API локално към една машина, то обекта се обменя ефективно в паметта, например чрез памет, предназначена за единствен процес, или между няколко процеса, използвайки споделена памет, сървърно приложение или други технологии за споделяне като tuple space.

 

Отдалеченото API за обекти е базирано на отдалечен протокол, като CORBA, който позволява извикване на отдалечен обектен метод. Извикване на метод, който е изпълнен локално върху прокси обект, извиква съответния метод върху отдалечение обект, използвайки отдалечен протокол, като изисква резултата да бъде използван локално като връщана стойност.

 

Когато отдалечението е на място, модификация на прокси обекта отговаря на модификация на отдалечение обект. Когато имаме само трансфер на обект, модификацията на локалното копие на обекта не е рефлектирано върху оригиналния обект, освен ако обекта не е изпратен към изпращаща система.

 

Уеб API е приложно-програмен интерфейс, предназначен за уеб сървър или уеб браузър. Концепцията за API е като архитектура, която се върти около предоставянето на програмни интерфейси към група от услуги към различни приложения, обслужвайки различни видове потребители. Когато се използва в контекста на уеб програмиране, едно API е дефинирано като група от HTTP извикващи съобщения, заедно с дефиниция на структурата на отговарящите съобщения, което обикновено е при Extensible Markup Language (XML) или Java Script Object Notation (JSON) формат. Докато “уеб API” исторически е синоним на уеб услуга, според последните тенденции (така наречената Web 2.0) значението на термина се измества от Simple Object Access Protocol (SOAP) базирани уеб услуги и архитектура, ориентирана към услугите (SOA) към по-директно REST стил уеб източници и архитектура, ориентирана към източниците (ROA). Част от тази тенденция е свързана с движенето на семантичния уеб към Resource Description Framework (RDF), концепция за промотиране на уеб базирани онтологични инженерни технологии. Уеб API-тата позволяват комбинацията на множество API-та в нови приложения, известни като mashups.

 

Практиката за публикуване на API-та позволи на уеб общността да създава отворена архитектура за споделяне на съдържание и данни между общности и приложения. По този начин съдържание, което е създадено на едно място може динамично да бъде публикувано и обновено на няколко места в уеб пространството:

 

Снимките могат да бъдат споделяни от сайтове, като Flickr и Photobucket към социални мрежи като Facebook и MySpace.

 

Съдържанието може да бъде вмъкнато, като например вмъкване на презентация от SlideShare в LinkedIn профил.

 

Съдържанието може да бъде публикувано динамично. Споделянето на коментари в реално време, направени в Twitter с Facebook акаунт например е възможно благодарение на техните API-та.

 

Видео съдържание може да бъде вмъквано в сайтове, обслужвани от друг хост.

 

Информация за потребителя може да бъде споделяна от уеб общността към външни приложения, предоставяйки нова функционалност на уеб обществото, което споделя неговите данни за потребителя чрез отворено API. Един от най-добрите примери за това е Facebook Application platform и Open Social platform.

 

Ако съдържанието е директно представяне на физическия свят (например температура за някое място на земята) тогава едно API може да бъде считано за “Environmental Programming Interface" (EPI).