Какво е API? Обяснени интерфейси за приложно програмиране

API означава интерфейс за програмиране на приложения, концепция, която се прилага навсякъде - от инструменти на командния ред до корпоративен Java код до уеб приложения Ruby on Rails. API е начин за програмно взаимодействие с отделен софтуерен компонент или ресурс.

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

Какво е API?

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

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

Едно нещо, което трябва да имате предвид, е, че името на някои API често се използва, за да се отнесе както към спецификацията на взаимодействията, така и към действителния софтуерен компонент, с който взаимодействате. Фразата „Twitter API“ например не само се отнася до набора от правила за програмно взаимодействие с Twitter, но обикновено се разбира нещото, с което взаимодействате, както в „Правим анализ на туитовете, от които получихме API на Twitter. "

API като абстракционен слой

Що се отнася до софтуера, API са буквално навсякъде. Приложните програмни интерфейси вървят ръка за ръка с една от най-фундаменталните концепции в компютърните науки: абстракция. Абстракцията е просто начин за организиране на сложността на системата, така че сложните действия да могат да бъдат обработвани по прост начин. Помислете за тази абстракция като онези бутони на Amazon Dash, батерийни платки с бутони, които можете да използвате, за да поръчате скоби от Amazon. Ето как изглеждат те:

Поръчвате тире бутон от Amazon и използвате приложение на смартфона си, за да го свържете с вашата Wi-Fi мрежа, вашия акаунт в Amazon и продукт, да речем, любимата ви марка хартиени кърпи. След това, когато искате да поръчате още хартиени кърпи, просто натиснете бутона. Бутонът за тире се свързва с интернет и изпраща съобщение за поръчка във вашия акаунт. Няколко дни по-късно хартиени кърпи пристигат на прага ви.

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

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

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

Публични API и интегриране на API

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

Този вид кодови смеси позволяват на потребителите да комбинират и съчетават функционалността на различни доставчици в собствените си системи. Например, ако използвате софтуера за маркетингова автоматизация Marketo, можете да синхронизирате данните си там с функционалността на Salesforce CRM.

„Отворено“ или „публично“ не трябва да се тълкува като „безплатно“ в този контекст. Все още трябва да сте клиент на Marketo и Salesforce, за да работи това. Но наличността на тези API прави интеграцията много по-опростен процес, отколкото би бил в противен случай. ( има чудесен списък с публични API, за които трябва да знаете.)

Уеб услуги и API

Може да си припомните термина w eb услуги от началото на 00-те и да мислите, че идеята за отворен API звучи доста подобно. Всъщност уеб услугата е специфичен вид отворен API, който отговаря на доста строг набор от спецификации, включително че те трябва да бъдат посочени в езика за описание на уеб услуги (WSDL), XML вариант.

Уеб услугите трябваше да се използват като част от ориентирана към услуги архитектура (SOA). Както обяснява блогът на Nordic APIs, това дава на уеб услугите нещо лошо име, тъй като SOA никога не оправдават потенциала си. Напредъкът в техниките, използвани за комуникация от услуга към услуга - особено по-лек и по-гъвкав REST - също остави уеб услугите малко назад в света на публичните API.

REST API

Уеб услугите първоначално са проектирани да комуникират чрез SOAP (Simple Object Access Protocol), протокол за съобщения, който изпраща XML документи през HTTP. Днес обаче повечето уеб-базирани API използват REST - Представителен държавен трансфер - като архитектурен стил.

REST беше официално представен от Рой Филдинг в неговата докторска дисертация през 2000 г. Това е набор от архитектурни компоненти, принципи на проектиране и взаимодействия, използвани за изграждане на разпределени системи, които включват медии от всякакъв вид (текст, видео и т.н.). В основата си REST е стил на изграждане на системи, който позволява гъвкава комуникация и показване на информация в мрежата, като същевременно осигурява структура, необходима за лесно изграждане на компоненти с общо предназначение.

В REST API ресурс може да бъде почти всичко, но примерите включват потребител, списък с туитове и текущите резултати от търсене на туитове. Всеки от тези ресурси е адресируем с идентификатор на ресурс , който в случая на уеб базирани REST API обикновено е URL адрес, като //api.twitter.com/1.1/users/show?screen_name=twitterdev. Когато приложението поиска ресурс, използвайки идентификатора, API предоставя текущото представяне на този ресурс на приложението във формат, който приложението може да използва, като JPEG изображение, HTML страница или JSON.

Един от големите разграничители на REST е, че включва изпращане на данни до заявяващото приложение. Въпреки че това осигурява голяма гъвкавост, позволявайки на приложението да прави каквото пожелае с данните, това се дължи на ефективността. Изпращането на данни през мрежата за обработка е доста бавно в сравнение с обработката, където данните се намират, и след това изпращането на резултатите.

Разбира се, проблемът с „ефективния“ подход е, че системите, хостващи данните, трябва да знаят какво приложения искат да правят с тях преди време. По този начин, за да се изгради API, който има общо предназначение и гъвкавост, REST е пътят.

Примери за API

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

  • Приложни програмни интерфейси (API) на Google , които ви позволяват да свържете кода си с цялата гама от услуги на Google, от Maps до Translate. API са толкова важни за Google, че са придобили Apigee, водеща платформа за управление на API.
  • API на Facebook , които ви позволяват програмно да получите достъп до социалната графика и маркетинговите инструменти на Facebook. (Компанията ограничава точно до какви потребителски данни можете да осъществите достъп чрез тези API в последствията от Cambridge Analytica и други скандали.)

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

API на Java

Java API е библиотека от софтуерни компоненти, достъпна „от кутията“ за всеки, който е инсталирал Java Development Kit. Тези компоненти изпълняват общи задачи и обикновено увеличават производителността, защото програмистите не трябва да започват отначало всеки път. Един от основните компоненти, използвани в софтуера, е нещо, наречено Списък, което, както може да се очаква, проследява списък с елементи. Java API определя какво можете да правите със списък: добавяне на елементи, сортиране на списъка, определяне дали даден елемент е в списъка и т.н. Той също така посочва как да извършите тези действия. За да сортирате списъка, трябва да посочите как искате списъкът да бъде сортиран: по азбучен ред, числово низходящ, най-ярък до най-тъпен цвят и т.н.

API на Twitter

Twitter API е уеб базиран JSON API, който позволява на разработчиците да взаимодействат програмно с данните в Twitter. За разлика от Java API, който е включен в Java Development Kit, Twitter API е уеб базиран API. Достъпът до него трябва да се извършва чрез отправяне на заявки през Интернет към услуги, които Twitter хоства.

С уеб-базиран API, като Twitter, вашето приложение изпраща HTTP заявка, точно както прави уеб браузърът. Но вместо отговорът да се достави като уеб страница, за разбиране от човека, той се връща във формат, който приложенията могат лесно да анализират. За тази цел съществуват различни формати, а Twitter използва популярен и лесен за използване формат, наречен JSON. (Ако не сте запознати с JSON, може да искате да отделите няколко минути за четене тук.)

Един от основните елементи в Twitter е туит. API на Twitter ви казва какво можете да правите с туитове: търсете туитове, създайте туит, любим туит. Той също така ви казва как да извършите тези действия. За да търсите туитове, трябва да посочите критериите си за търсене: термини или хаштагове, които да търсите, геолокация, език и т.н.

API дизайн

Дизайнът на API е процесът, чрез който се формулират „какво“ и „как“ на API. Както при всичко друго, което може да бъде създадено, в дизайна на API се влагат различни нива на мисъл и грижа, което води до различни нива на качество на API. Добре проектираните приложни програмни интерфейси (API) имат последователно поведение, вземат предвид контекста им и имат предвид нуждите на своите потребители.

Последователното поведение в даден API силно влияе върху скоростта, с която може да се научи, и вероятността програмистите да правят грешки при използването му. Като цяло API, които извършват подобни действия, трябва да се държат по подобен начин, независимо от техническите им различия. За пример за непостоянен API, нека разгледаме двата начина за добавяне на елемент към Списък в Java:

Въпреки че двата метода за добавяне на елементи към списък правят едно и също нещо, техните типове на връщане (логически и void) са различни. Разработчиците, използващи този API, сега трябва да следят кой метод връща кой тип, което прави API по-труден за научаване и използването му по-податливо на грешки. Това също означава, че кодът, който използва тези методи, става по-малко гъвкав, защото трябва да се промени, ако искате да превключите начина, по който добавяте елементи.

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