Лекция
API (программный интерфейс приложения, интерфейс прикладного программирования) (англ. application programming interface, API [эй-пи-ай] ) — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой. Обычно входит в описание какого-либо интернет-протокола (например, RFC ), программного каркаса (фреймворка) или стандарта вызовов функций операционной системы . Часто реализуется отдельной программной библиотекой или сервисом операционной системы. Используется программистами при написании всевозможных приложений.
Интерфейс прикладного программирования (API - Application Programming Interface) это интерфейс, позволяющий различным программным компонентам взаимодействовать друг с другом.
API может быть применен несколькими способами:
интерфейс программирования приложений (API, application programming interface) это набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах. Используется программистами для написания различных приложений.
API определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как эта функциональность реализована. Если программу (модуль, библиотеку) рассматривать как черный ящик, то API - это множество «ручек», которые доступны пользователю данного ящика, которые он может возвращать.
Программные компоненты взаимодействуют друг с другом с помощью API. При этом обычно компоненты образуют иерархию - высокоуровневые компоненты используют API низкоуровневых компонентов, а те, в свою очередь, используют API еще более низкоуровневых компонентов.
Если говорить более понятным языком, то API — это готовый код для упрощения жизни программисту. API создавался для того, чтобы программист реально мог облегчить задачу написания того или иного приложения благодаря использованию готового кода (например, функций). Всем известный jQuery, написанный на JavaScript является тоже своего рода API. Если рассматривать конкретно данный пример, то jQuery позволяет намного облегчить написание кода. То что обычными средствами JavaScript можно было сделать за 30 строк, через jQuery пишется через 5-6. Если рассматривать API в общем, то можно найти очень много сервисов, представляющих решения для разработки. Самый известный на сегодняшний день — это сервис code.google.com, предоставляющий около полусотни разнообразных API! Это и интерфейс для создания Android-приложений, и различные API для работы с AJAX, и различные API приложений, которые можно легко подстроить под свой лад.
Интерфейс прикладного программирования ( API ) — это соединение между компьютерами или между компьютерными программами . Это тип программного интерфейса , предлагающий услугу другим частям программного обеспечения . Документ или стандарт, описывающий, как построить такое соединение или интерфейс, называется спецификацией API . Говорят, что компьютерная система, соответствующая этому стандарту, реализует или предоставляет API. Термин API может относиться как к спецификации, так и к реализации.
В отличие от пользовательского интерфейса , который соединяет компьютер с человеком, интерфейс прикладного программирования соединяет компьютеры или части программного обеспечения друг с другом. Он не предназначен для непосредственного использования человеком ( конечным пользователем ), кроме программиста , который включает его в программное обеспечение. API часто состоит из различных частей, которые действуют как инструменты или службы, доступные программисту. Говорят, что программа или программист, которые используют одну из этих частей, вызывают эту часть API. Вызовы, составляющие API, также известны как подпрограммы , методы, запросы или конечные точки . Спецификация API определяет эти вызовы, то есть объясняет, как их использовать или реализовывать.
Одной из целей API является сокрытие внутренних деталей работы системы, показывая только те части, которые программист сочтет полезными, и сохраняя их согласованность, даже если внутренние детали впоследствии изменятся. API может быть специально разработан для конкретной пары систем или может быть общим стандартом, обеспечивающим взаимодействие между многими системами.
Термин API часто используется для обозначения веб-API , которые обеспечивают связь между компьютерами, подключенными к Интернету . Существуют также API для языков программирования , библиотек программного обеспечения , компьютерных операционных систем и компьютерного оборудования . API возникли в 1940-х годах, хотя сам термин появился только в 1960-х и 1970-х годах.
Ведь есть ли смысл писать код своими руками? Зачем трудиться над тем, что уже создано? Разве есть смысл отказываться от бесплатных решений (а фактически, и от бесплатной помощи) в web разработке? Если вы ответили на все эти вопросы «НЕТ», то считайте, что вы поняли суть API.
Но еще хочу оговориться. Начинающим разработчикам НЕ следует пользоваться полуготовыми решениями, так как в будущем они не справятся с реальной задачей. Поэтому, если вы начинающий web программист, то не используйте полуфабрикаты! Учитесь думать своей головой, строить различные алгоритмы, чтобы понять суть программирования. Так же говорю, уже обращаясь ко всем, что API — это не готовые решения, это среда, интерфейс для создания своих проектов. Вы же не едите замороженный котлеты из магазина? Вы сначала их пожарите, не так ли? Эта аналогия очень ясно отображает суть API.
API определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.
Если программу (модуль, библиотеку) рассматривать как черный ящик, то API — это множество «ручек», которые доступны пользователю данного ящика и которые он может вертеть и дергать.
Программные компоненты взаимодействуют друг с другом посредством API. При этом обычно компоненты образуют иерархию — высокоуровневые компоненты используют API низкоуровневых компонентов, а те, в свою очередь, используют API еще более низкоуровневых компонентов.
По такому принципу построены протоколы передачи данных по Интернету. Стандартный стек протоколов (сетевая модель OSI) содержит 7 уровней (от физического уровня передачи бит до уровня протоколов приложений, подобных протоколам HTTP и IMAP). Каждый уровень пользуется функциональностью предыдущего («нижележащего») уровня передачи данных и, в свою очередь, предоставляет нужную функциональность следующему («вышележащему») уровню.
Понятие протокола близко по смыслу к понятию API. И то, и другое является абстракцией функциональности, только в первом случае речь идет о передаче данных, а во втором — о взаимодействии приложений.
API библиотеки функций и классов включает в себя описание сигнатур и семантики функций.
Сигнатура функции — часть общего объявления функции, позволяющая средствам трансляции идентифицировать функцию среди других. В различных языках программирования существуют разные представления о сигнатуре функции, что также тесно связано с возможностями перегрузки функций в этих языках.
Иногда различают сигнатуру вызова и сигнатуру реализации функции. Сигнатура вызова обычно составляется по синтаксической конструкции вызова функции с учетом сигнатуры области видимости данной функции, имени функции, последовательности фактических типов аргументов в вызове и типе результата. В сигнатуре реализации обычно участвуют некоторые элементы из синтаксической конструкции объявления функции: спецификатор области видимости функции, ее имя и последовательность формальных типов аргументов.
Например, в языке программирования C++ простая функция однозначно опознается компилятором по ее имени и последовательности типов ее аргументов, что составляет сигнатуру функции в этом языке. Если функция является методом некоторого класса, то в сигнатуре будет участвовать и имя класса.
В языке программирования Java сигнатуру метода составляет его имя и последовательность типов параметров; тип возвращаемого значения в сигнатуре не участвует.
Семантика функции — это описание того, что данная функция делает. Семантика функции включает в себя описание того, что является результатом вычисления функции, как и от чего этот результат зависит. Обычно результат выполнения зависит только от значений аргументов функции, но в некоторых модулях есть понятие состояния. Тогда результат функции может зависеть от этого состояния, и, кроме того, результатом может стать изменение состояния. Логика этих зависимостей и изменений относится к семантике функции. Полным описанием семантики функций является исполняемый код функции или математическое определение функции.
API открывает программную систему для взаимодействия извне. Он позволяет двум программным системам общаться через границу — интерфейс — используя взаимно согласованные сигналы. Другими словами, API соединяет программные сущности вместе. В отличие от пользовательского интерфейса , API обычно не виден пользователям. Это часть программной системы «под капотом», используемая для межмашинного взаимодействия.
Хорошо спроектированный API выставляет только объекты или действия, необходимые программному обеспечению или разработчикам программного обеспечения. Он скрывает детали, которые не имеют смысла. Эта абстракция упрощает программирование.
Образно говоря, API связывают программное обеспечение подобно взаимосвязанным блокам.
Создание программного обеспечения с использованием API можно сравнить с использованием конструкторов, таких как кубики Lego . Программные службы или библиотеки программного обеспечения аналогичны кубикам; они могут быть объединены вместе с помощью своих API, составляя новый программный продукт. Процесс объединения называется интеграцией .
В качестве примера рассмотрим датчик погоды, который предлагает API. Когда определенное сообщение передается датчику, он определяет текущие погодные условия и отвечает прогнозом погоды. Сообщение, которое активирует датчик, является вызовом API , а прогноз погоды является ответом API . Приложение прогнозирования погоды может интегрироваться с несколькими API датчиков погоды, собирая данные о погоде со всей географической области.
API часто сравнивают с контрактом . Он представляет собой соглашение между сторонами: поставщиком услуг, который предлагает API, и разработчиками программного обеспечения, которые полагаются на него. Если API остается стабильным или если он изменяется только предсказуемым образом, доверие разработчиков к API возрастет. Это может увеличить их использование API.
Диаграмма 1978 года, предлагающая расширение идеи API с целью превращения его в общий программный интерфейс, выходящий за рамки только прикладных программ [ 9 ]
Термин API изначально описывал интерфейс только для программ, ориентированных на конечного пользователя, известных как прикладные программы . Это происхождение все еще отражено в названии «интерфейс прикладного программирования». Сегодня этот термин шире, включая также служебное программное обеспечение и даже аппаратные интерфейсы . [ 10 ]
Идея API намного старше самого термина. Британские ученые-компьютерщики Морис Уилкс и Дэвид Уиллер работали над модульной библиотекой программного обеспечения в 1940-х годах для EDSAC , одного из первых компьютеров. Подпрограммы в этой библиотеке хранились на перфоленте, организованной в картотеке . В этой библиотеке также содержалось то, что Уилкс и Уиллер называли «библиотечным каталогом» заметок о каждой подпрограмме и о том, как включить ее в программу. Сегодня такой каталог называли бы API (или спецификацией API или документацией API), потому что он инструктирует программиста о том, как использовать (или «вызывать») каждую подпрограмму, которая нужна программисту.
Книга Уилкса и Уиллера «Подготовка программ для электронного цифрового компьютера » содержит первую опубликованную спецификацию API. Джошуа Блох считает, что Уилкс и Уиллер «скрыто изобрели» API, поскольку это скорее концепция, которая была обнаружена, чем изобретена.
Хотя люди, придумавшие термин API, реализовывали программное обеспечение на Univac 1108 , целью их API было сделать возможным создание программ, независимых от оборудования .
Термин «интерфейс прикладной программы» (без суффикса -ing ) впервые упоминается в статье под названием « Структуры данных и методы удаленной компьютерной графики» , представленной на конференции AFIPS в 1968 году. Авторы этой статьи используют этот термин для описания взаимодействия приложения — в данном случае графической программы — с остальной частью компьютерной системы. Последовательный интерфейс приложения (состоящий из вызовов подпрограмм Fortran ) был призван освободить программиста от необходимости иметь дело с особенностями графического устройства отображения и обеспечить аппаратную независимость в случае замены компьютера или дисплея. [
Термин был введен в область баз данных CJ Date в статье 1974 года под названием « Реляционный и сетевой подходы: сравнение интерфейса прикладного программирования» . API стал частью фреймворка ANSI/SPARC для систем управления базами данных . Этот фреймворк рассматривал интерфейс прикладного программирования отдельно от других интерфейсов, таких как интерфейс запросов. Профессионалы в области баз данных в 1970-х годах заметили, что эти различные интерфейсы можно объединить; достаточно богатый интерфейс приложения мог поддерживать и другие интерфейсы.
Это наблюдение привело к API, которые поддерживали все типы программирования, а не только прикладное программирование. К 1990 году API был определен просто как «набор услуг, доступных программисту для выполнения определенных задач» технологом Карлом Маламудом .
Скриншот документации Web API , написанной NASA
Идея API снова была расширена с рассветом удаленных вызовов процедур и веб-API . Поскольку компьютерные сети стали обычным явлением в 1970-х и 80-х годах, программисты хотели вызывать библиотеки, расположенные не только на их локальных компьютерах, но и на компьютерах, расположенных в других местах. Эти удаленные вызовы процедур хорошо поддерживались языком Java , в частности. В 1990-х годах, с распространением Интернета , такие стандарты, как CORBA , COM и DCOM, конкурировали за то, чтобы стать наиболее распространенным способом предоставления API-сервисов. [
В диссертации Роя Филдинга « Архитектурные стили и проектирование сетевых программных архитектур» в Калифорнийском университете в Ирвайне в 2000 году была описана передача репрезентативного состояния (REST) и описана идея «сетевого интерфейса прикладного программирования», который Филдинг противопоставил традиционным «библиотекарным» API. [ 17 ] Веб-API XML и JSON получили широкое коммерческое внедрение, начавшееся в 2000 году и продолжавшееся по состоянию на 2021 год. Веб-API в настоящее время является наиболее распространенным значением термина API.
Семантическая паутина, предложенная Тимом Бернерсом-Ли в 2001 году, включала «семантические API», которые переделали API в открытый , распределенный интерфейс данных, а не интерфейс поведения программного обеспечения. Проприетарные интерфейсы и агенты стали более распространенными, чем открытые, но идея API как интерфейса данных укрепилась. Поскольку веб-API широко используются для обмена данными всех видов в сети, API стал широким термином, описывающим большую часть общения в Интернете. При таком использовании термин API имеет совпадение по значению с термином протокол связи .
Интерфейс к программной библиотеке — это один из типов API. API описывает и предписывает «ожидаемое поведение» (спецификация), тогда как библиотека — это «реальная реализация» этого набора правил.
Один API может иметь несколько реализаций (или не иметь ни одной, поскольку он абстрактный) в виде различных библиотек, которые совместно используют один и тот же программный интерфейс.
Разделение API от его реализации может позволить программам, написанным на одном языке, использовать библиотеку, написанную на другом. Например, поскольку Scala и Java компилируются в совместимый байт-код , разработчики Scala могут использовать преимущества любого API Java. [ 19 ]
Использование API может варьироваться в зависимости от типа используемого языка программирования. API для процедурного языка, такого как Lua, может состоять в основном из базовых процедур для выполнения кода, манипулирования данными или обработки ошибок, в то время как API для объектно-ориентированного языка , такого как Java, будет предоставлять спецификацию классов и их методов класса . [ 20 ] [ 21 ] Закон Хайрама гласит: «При достаточном количестве пользователей API не имеет значения, что вы обещаете в контракте: все наблюдаемые поведения вашей системы будут зависеть от кого-то». [ 22 ] Между тем, несколько исследований показывают, что большинство приложений, использующих API, как правило, используют лишь небольшую часть API. [ 23 ]
Языковые привязки также являются API. Сопоставляя функции и возможности одного языка с интерфейсом, реализованным на другом языке, языковая привязка позволяет использовать библиотеку или службу, написанную на одном языке, при разработке на другом языке. [ 24 ] Такие инструменты, как SWIG и F2PY, генератор интерфейсов Fortran -to -Python , облегчают создание таких интерфейсов. [ 25 ]
API также может быть связан с программной средой : среда может быть основана на нескольких библиотеках, реализующих несколько API, но в отличие от обычного использования API, доступ к поведению, встроенному в среду, осуществляется путем расширения ее содержимого новыми классами, подключенными к самой среде.
Более того, общий поток управления программой может выйти из-под контроля вызывающей стороны и оказаться в руках фреймворка посредством инверсии управления или аналогичного механизма. [ 26 ] [ 27 ]
API может определять интерфейс между приложением и операционной системой . [ 28 ] Например, POSIX определяет набор общих API, которые позволяют приложению, написанному для операционной системы, соответствующей POSIX, быть скомпилированным для другой операционной системы, соответствующей POSIX.
Linux и Berkeley Software Distribution являются примерами операционных систем, реализующих API POSIX
Microsoft продемонстрировала твердую приверженность обратно совместимому API, особенно в своей библиотеке Windows API (Win32), поэтому старые приложения могут работать в новых версиях Windows, используя специфичную для исполняемого файла настройку, называемую «Режим совместимости».
API отличается от двоичного интерфейса приложения (ABI) тем, что API основан на исходном коде, а ABI — на двоичном . Например, POSIX предоставляет API, а Linux Standard Base предоставляет ABI.
Удаленные API позволяют разработчикам манипулировать удаленными ресурсами через протоколы , специальные стандарты для связи, которые позволяют различным технологиям работать вместе, независимо от языка или платформы. Например, Java Database Connectivity API позволяет разработчикам запрашивать множество различных типов баз данных с тем же набором функций, в то время как Java remote method invocation API использует Java Remote Method Protocol, чтобы разрешить вызов функций, которые работают удаленно, но кажутся локальными для разработчика.
Таким образом, удаленные API полезны для поддержания абстракции объектов в объектно-ориентированном программировании ; вызов метода , выполняемый локально на прокси- объекте, вызывает соответствующий метод на удаленном объекте, используя протокол удаленного взаимодействия, и получает результат для локального использования в качестве возвращаемого значения.
Изменение прокси-объекта также приведет к соответствующему изменению удаленного объекта.
Веб-API — это определенные интерфейсы, через которые происходит взаимодействие между предприятием и приложениями, использующими его активы, что также является соглашением об уровне обслуживания (SLA) для указания функционального поставщика и предоставления пути обслуживания или URL для пользователей API. Подход API — это архитектурный подход, который вращается вокруг предоставления программного интерфейса для набора услуг для различных приложений, обслуживающих различные типы потребителей
При использовании в контексте веб-разработки API обычно определяется как набор спецификаций, таких как сообщения-запросы Hypertext Transfer Protocol (HTTP), а также определение структуры ответных сообщений, обычно в формате Extensible Markup Language ( XML ) или JavaScript Object Notation ( JSON ). Примером может служить API судоходной компании, который можно добавить на веб-сайт, ориентированный на электронную коммерцию, чтобы упростить заказ услуг по доставке и автоматически включать текущие тарифы на доставку, без необходимости для разработчика сайта вводить таблицу тарифов грузоотправителя в веб-базу данных. Хотя «веб-API» исторически был фактически синонимом веб-сервиса , недавняя тенденция (так называемый Web 2.0 ) отходит от веб-сервисов на основе Simple Object Access Protocol ( SOAP ) и сервисно-ориентированной архитектуры (SOA) в сторону веб-ресурсов в стиле более прямой передачи репрезентативного состояния (REST) и ресурсно-ориентированной архитектуры (ROA). Часть этой тенденции связана с движением Semantic Web к Resource Description Framework (RDF), концепции продвижения веб- технологий разработки онтологий . Веб-API позволяют объединять несколько API в новые приложения, известные как мэшапы . В сфере социальных сетей веб-API позволили веб-сообществам облегчить обмен контентом и данными между сообществами и приложениями. Таким образом, контент, который создается в одном месте динамически, может быть опубликован и обновлен в нескольких местах в сети. Например, REST API Twitter позволяет разработчикам получать доступ к основным данным Twitter, а API поиска предоставляет разработчикам методы для взаимодействия с данными поиска и трендов Twitter.
Практически все операционные системы (UNIX, Windows, OS X и т. д.) имеют API, с помощью которого программисты могут создавать приложения для этой операционной системы. Главный API операционных систем — это множество системных вызовов.
В индустрии программного обеспечения общие стандартные API для стандартной функциональности играют важную роль, так как они гарантируют, что все программы, использующие общий API, будут работать одинаково хорошо или, по крайней мере, типичным привычным образом. В случае API графических интерфейсов это означает, что программы будут иметь похожий пользовательский интерфейс, что облегчает процесс освоения новых программных продуктов.
С другой стороны, отличия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности — написание «промежуточных» API (API графических интерфейсов wxWidgets, 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, таким образом, являются:
Используется в веб-разработке, как правило, определенный набор HTTP-запросов, а также определение структуры HTTP-ответов, для выражения которых используют XML или JSON форматы.
Web API является практически синонимом для веб-службы, хотя в последнее время за счет тенденции Web 2.0 осуществлен переход от SOAP к REST типу коммуникации. Веб-интерфейсы, обеспечивающие сочетание нескольких сервисов в новых приложениях, известны как гибридные.
Примеры: MediaWiki API
API для сайта - это скрипт, который принимает запросы (по методам GET (site.ru / api.php: A = b), POST) и возвращает не обычный HTML для браузеров, а результат запроса в определенном формате (XML, JSON, php serialize () -ed).
АРИ предназначен не для пользователей, а для скрипта со стороннего сайта / сервиса / программы, который посылает эти GET / POST запросы, получает результат и использует данные. Запросы скрипт посылает чтобы выполнить определенное действие (например, как действие, которое выполняют пользователи сайта через браузер).
Разработчикам-программистам АРЕ нужен для интеграции с другими сайтами / сервисами программами, или автоматизации определенных действий. Обычно, АРЕ создаются для очень популярных сайтов или сервисов.
Дизайн API оказывает значительное влияние на его использование. Принцип сокрытия информации описывает роль интерфейсов программирования как обеспечение модульного программирования путем сокрытия деталей реализации модулей, чтобы пользователям модулей не нужно было понимать сложности внутри модулей.Таким образом, дизайн API пытается предоставить только те инструменты, которые пользователь ожидает.Дизайн интерфейсов программирования представляет собой важную часть архитектуры программного обеспечения , организацию сложного фрагмента программного обеспечения.
JSON, удобный и human-readable,
Бинарные и более современные технологии: BSON, CBOR, MessagePack.
Требования к формату представления данных, используемые в REST API:
бинарный;
быстрый (с поддержкой Zero-copy);
без схемы;
поддерживаются существующие в JSON типы для конвертации.
Например MessagePack, позволяет ускорить прак тически на половину относительно JSON, что позволит увеличить вовлеченность или конверсию.
При разработке API используются разные форматы данных для передачи информации между клиентом и сервером. Основные из них: JSON, XML, YAML, Protobuf, MessagePack и Avro. Рассмотрим их особенности, преимущества и недостатки.
| Формат | Описание | Преимущества | Недостатки | Применение |
|---|---|---|---|---|
| JSON (JavaScript Object Notation) | Читаемый текстовый формат, основанный на JavaScript-объектах. | Легко читается человеком и машиной. Широкая поддержка в языках программирования. Хорошо сжимается. | Неэффективен по размеру (из-за дублирования ключей). Медленнее двоичных форматов. | REST API, Web-сервисы, микросервисы. |
| XML (Extensible Markup Language) | Тегированный текстовый формат с вложенной структурой. | Гибкость и расширяемость. Поддерживает валидацию (XSD, DTD). Читаем человеком. | Избыточность, большой размер. Медленнее JSON. Сложность парсинга. | SOAP API, конфигурационные файлы, финансовые системы. |
| YAML (Yet Another Markup Language) | Упрощенный формат разметки, удобный для конфигураций. | Читаемый человеком. Минимум символов, легче JSON и XML. Поддерживает вложенность. | Медленнее JSON и двоичных форматов. Чувствителен к отступам. | Конфигурации (Kubernetes, Docker, Ansible), OpenAPI. |
| Protobuf (Protocol Buffers) | Двоичный формат от Google для высокопроизводительной передачи данных. | Компактность и высокая скорость. Хорош для мобильных и IoT-приложений. Поддержка схем. | Не читаем человеком. Требует компиляции схемы (protobuf definition). | gRPC, внутренние API, высоконагруженные системы. |
| MessagePack | Двоичный формат, оптимизированный для JSON-объектов. | Компактнее JSON. Поддерживает сложные структуры данных. Высокая скорость сериализации. | Требует библиотеки для парсинга. Не так широко распространен, как JSON. | IoT, мобильные приложения, быстрые API. |
| Avro | Двоичный формат с динамическими схемами от Apache. | Высокая производительность. Хорошо сжимается. Поддержка эволюции схем (без необходимости перекомпиляции). | Требует использования схемы. Менее распространен. | Big Data, Apache Kafka, распределенные системы. |
Если важны читаемость и простота, выбирайте JSON или YAML.
Если приоритет — производительность, используйте Protobuf или MessagePack.
Для Big Data и сложных структур
продолжение следует...
Часть 1 API. Интерфейс программирования приложений
Часть 2 Виджеты и гаджеты - API. Интерфейс программирования приложений
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Основы интернет и веб технологий
Термины: Основы интернет и веб технологий