API свързват приложения чрез ясни протоколи и архитектури. Архитектурата на API е рамка от правила за създаване на софтуерни интерфейси. Правилата определят как да се предостави функционалност на сървъра на потребителите. Типът архитектура определя правилата и структурите, които управляват API.
Има много различни видове API архитектура, от REST до RPC. Научаването на тяхната структура и състав ще ви помогне да изберете един за вашето приложение.
1. ПОЧИВКА
API на REST са модерни и са най-популярната API архитектура, която разработчиците използват. ПОЧИВКА (представителен трансфер на състояние) е архитектура, използвана за проектиране на приложения клиент-сървър. Това не е протокол или стандарт, така че можете да го внедрите по различни начини. Този аспект увеличава вашата гъвкавост като разработчик.
REST позволява достъп до исканите данни, съхранявани в база данни. Можете да изпълнявате основните CRUD функции с REST API. Когато клиентите поискат съдържание чрез RESTful API, те трябва да използват правилните заглавки и параметри. Заглавките съдържат полезни метаданни за идентифициране на ресурс, като кодове за състояние и оторизация.
Информацията, прехвърлена чрез HTTP, може да бъде в JSON, HTML, XML или обикновен текст. JSON е най-често използваният файлов формат за REST API. JSON е езиково агностичен и четим от хората.
2. САПУН
Прост протокол за достъп до обекти (SOAP) е официален API протокол. World Wide Web Consortium (W3C) поддържа SOAP протокола, който е една от най-ранните API архитектури. Неговият дизайн улеснява комуникацията между приложения, създадени с различни езици и платформи.
SOAP форматът описва API, използвайки езика за описание на уеб услуги (WSDL). Написан е на обширния език за маркиране (XML). Форматът налага вградени стандарти за съответствие, които повишават сигурността, последователността, изолацията и издръжливостта. Тези свойства гарантират надеждни транзакции на бази данни, което прави SOAP по-добър за корпоративно развитие.
Когато потребител поиска съдържание чрез SOAP API, то преминава през стандартните протоколи на слоя. Отговорът е в XML формат, който хората и машините могат да четат. Подобно на REST API, SOAP API не кешират/съхраняват информация. Ако имате нужда от данните по-късно, трябва да направите друга заявка.
SOAP поддържа както обмен на данни със състояние, така и без състояние.
3. GraphQL
GraphQL е език за заявки за API. Това е среда за изпълнение от страна на сървъра, която изпълнява заявки въз основа на определен набор от данни. GraphQL има специфични случаи на употреба. Архитектурата му позволява да декларирате конкретната информация, от която се нуждаете.
За разлика от REST архитектурата, където HTTP обработва клиентските заявки и отговори, GraphQL изисква данни със заявки. Услуга GraphQL дефинира типовете и полетата на тези типове, след което предоставя функции за всяко поле и тип.
Услугата получава GraphQL заявки за валидиране и изпълнение. Първо, той проверява заявка, за да се увери, че се отнася до дефинираните типове и полета. След това изпълнява свързаните функции, за да произведе желания резултат.
GraphQL е страхотен за определени случаи на употреба, като извличане на данни от множество източници. Можете също така да контролирате извличането на данни и да регулирате честотната лента за по-малки устройства.
4. Апаш Кафка
Апаш Кафка е разпределена платформа, която поддържа стрийминг на събития. Поточното предаване на събития е процес на улавяне на данни в реално време от източници. Източниците могат да бъдат бази данни, сървъри или софтуерни приложения. Системата Kafka се състои от сървъри и клиенти. Комуникацията се осъществява чрез TCP мрежов протокол.
Можете да разположите системата на хардуер, виртуални машини и контейнери. Можете да направите това на място и в облачни среди. Системата Apache Kafka улавя данни, обработва и реагира на тях в реално време. Той може също така да насочва данните към предпочитана дестинация в реално време. Kafka улавя и съхранява данни в системата, които можете да извлечете по-късно за използване.
Kafka поддържа непрекъснат поток и интеграция на данни. Това гарантира, че информацията е на точното място и в точното време. Поточното предаване на събития може да се прилага за много случаи на употреба, които се нуждаят от потоци от данни на живо. Те включват финансови институции, здравеопазване, правителство, транспортна индустрия и компании за компютърен софтуер.
5. AsyncAPI
AsyncAPI е инициатива с отворен код, която помага за изграждането и поддържането на управлявани от събития архитектури. Спецификациите му имат много общи неща със спецификациите на OpenAPI. AsyncAPI по същество е адаптация и подобрение на спецификациите на OpenAPI, с няколко разлики.
Архитектурата AsyncAPI обединява комбинация от REST API и управлявани от събития API. Неговите схеми за обработка на заявки и отговори са подобно на това на API за събития. AsyncAPI предоставя спецификации за описание и документиране на асинхронни приложения в машинно четим вид формат. Той също така предоставя инструменти като генератори на кодове, за да улесни потребителите да ги прилагат.
AsyncAPI подобрява текущото състояние на управляваната от събития архитектура (EDA). Целта е да се улесни работата с EDA, както е с REST API. Инициативата AsyncAPI предоставя документация и код, които поддържат управление на събития. По-голямата част от процесите, използвани в REST API, се отнасят за управлявани от събития/асинхронни API.
Използването на спецификацията AsyncAPI за документиране на управлявани от събития системи е жизненоважно. Той управлява и поддържа последователност и ефективност в екипите, работещи по проекти, ръководени от събития.
6. Извикване на отдалечена процедура (RPC)
RPC е софтуерен комуникационен протокол, който позволява комуникация между различни програми в мрежа. Например, една програма може да поиска информация от друг компютър в мрежата. Не е необходимо да се придържа към мрежовите протоколи. Можете да използвате RPC за извикване на процеси на отдалечени системи точно както на локалната система.
RPC работи по модела клиент-сървър. Клиентската програма иска и сървърната програма отговаря с услуга. RPC работят в синхрон. Когато дадена програма изпрати заявка, тя остава спряна, докато не получи отговор от сървъра.
RPC са най-добри за разпределени системи. Те са най-добри за системи, базирани на команди, и имат леки полезни натоварвания, които увеличават производителността.
Как да изберете правилната API архитектура
Правилната API архитектура зависи от вашия случай на употреба. Архитектурата определя методологията за разработване на API и как ще работи. Архитектурният дизайн на API определя неговите компоненти и взаимодействия.
Вземете архитектурни решения, преди да проектирате и разработите API. Определете техническите изисквания на API, нивото, управлението на жизнения цикъл и сигурността. Архитектурните проекти на API съдържат структурни слоеве. Слоевете насочват разработката и гарантират, че създаденият API служи по предназначение.
