Интерфейс прикладной программы это

Интерфейс прикладной программы — интерфейс, посредством которого приложение получает доступ к операционной системе и другим сервисам.
Интерфейс прикладной программы обеспечивает предоставление четырех видов сервиса: системного, коммуникационного и информационного сервиса, а также интерфейса пользователя. Использование API позволяет одинаковым образом осуществлять обработку файлов, вывод на принтер, передачу сообщений и выполнение других операций.

Похожие термины:

Application Programming Interface — интерфейс прикладного программирования

стандартизированный набор функций, объектов и других программных компонентов, с помощью которых приложение запрашивает и выполняет сервисные функции низшего уровня, такие как развертывание и св

Источник: vocable.ru

Что такое API?

Если вам интересно, «Что такое API?» вы, возможно, не слышали этот термин раньше. Возможно, у вас есть смутное представление о том, что такое API и что оно делают. В любом случае, мы здесь, чтобы помочь разобраться.

Что такое интерфейс в ООП. Интерфейс c++ пример. Изучение С++ для начинающих. Урок #113

Определение API

API означает интерфейс прикладного программирования . Проще говоря, API — это набор функций и процедур, позволяющих создавать приложения. Они получают доступ к данным и функциям других приложений.

По сути, они являются посредниками для разных программных платформ. Они позволяют двум несвязанным приложениям «общаться» друг с другом.

Например, предположим, что вы биржевой маклер, по колено в финансовых рынках и трейдинге. API может связать набор алгоритмов автоматической торговли с предпочитаемой трейдером платформой торгового брокера. Это позволяет вам (трейдеру) видеть котировки и данные о ценах в режиме реального времени или проводить электронные сделки.

Хорошие API упрощают разработку компьютерной программы, предоставляя уже готовые блоки, которые затем собираются программистом. На самом деле API часто сравнивают с Lego по этой причине, потому что вы можете бесконечно смешивать, сочетать и повторно использовать их для создания новых сервисов.

Итак, что такое API?

Давайте приступим к этому и углубимся и разберем его на части:

1. Что такое API?
2. Что делает его другим?
3. Почему это так популярно?

Во-первых, API — это не база данных и даже не сервер; это код, который управляет точкой доступа к серверу. API — это как общий язык , механизм связи между разработчиками.

Реальный пример использования API

Еще один реальный пример использования API — покупка билетов в кино онлайн. Вы идете на сайт фильма; вводите свой фильм, имя и информацию о кредитной карте, и о чудо, вы распечатываете свои билеты.

Но задавались ли вы вопросом, что происходит между вводом информации и получением билета? API, вот что! Они являются связующим звеном в цифровом мире, сотрудничая за кулисами с другими приложениями, совершая «звонки» друг другу для доставки данных, которые необходимы в соответствии с запросом.

Впервые написал программу с графическим интерфейсом

Этот тип интеграции называется «бесшовным», потому что вы никогда не знаете, когда роль программного обеспечения переходит от одного приложения к другому.

Одна полезная аналогия — думать об API как о гостиничном консьерже . Когда вы останавливаетесь в отеле и вам что-то нужно, вы обращаетесь к консьержу, чтобы связаться с ним.

Это может быть что-то внутреннее, предоставляемое отелем, например бронирование ужина в ресторане отеля, или внешнее, например билеты на гольф или в театр. Консьерж упрощает вам доступ к этим различным услугам.

API-интерфейсы, по сути, являются консьержем цифрового мира — они позволяют предприятиям говорить на одном языке и обеспечивают глобальную цифровую экономику.

Зачем нам API?

Представьте себе следующий сценарий: вы (например, ваше приложение или ваш клиент, скажем, веб-браузер или мобильное приложение) хотите получить доступ к данным или функциям другого приложения.

Возможно, вы хотите получить доступ ко всем записям Telegram, в которых упоминается хэштег #itstalker.

Вы можете отправить электронное письмо в Твиттер и попросить электронную таблицу всех этих твитов. Но тогда вам придется найти способ импортировать эту таблицу в ваше приложение. Это не очень эффективный способ выполнить работу.

Почему? Даже если бы вы хранили их в базе данных, то данные очень быстро устарели бы. Было бы невозможно поддерживать его в актуальном состоянии.

Для Telegram было бы лучше и проще предоставить вам способ запрашивать их приложение, чтобы получить эти данные, чтобы вы могли просматривать или использовать их в своем приложении. Таким образом, он будет автоматически обновляться.

API предоставляет доступ к данным, поэтому эти данные могут быть включены в различные приложения. Вместо того, чтобы пытаться отформатировать большой файл в локальном приложении для извлечения небольшого количества данных, API предоставляет нужные вам данные без дополнительных исследований или манипуляций. Это гораздо более эффективный способ найти нужную информацию и подключить ее.

История API: SOAP XML V/S REST JSON API

Итак, откуда взялись API? Это зависит от того, кого вы спросите. По словам евангелиста API, Salesforce.com запустила первый онлайн-API 7 февраля 2000 года . Но API Salesforce не предназначались для общего доступа.

Также было сказано, что eBay начал создавать их для собственного использования в том же году. Итак, Salesforce и eBay часто приписывают внедрение самых старых API в истории, но история начинается не с этого.

В течение 2000-х SOAP-сервисы использовались для одних и тех же вариантов использования… а затем появился Рой Т. Филдинг.

Кто такой Рой Т. Филдинг?

В то же время, когда все это происходило (в 2000 году), Рой Филдинг представил то, что мы знаем как современные веб-API, в своей диссертации «Архитектурные стили и проектирование сетевых программных архитектур ». Другие формы были разработаны позже, создав совершенно новую индустрию онлайн-социального и корпоративного сотрудничества.

Филдинг — ученый-компьютерщик и видная фигура в индустрии сетевого программного обеспечения. Будучи аспирантом Калифорнийского университета в Ирвине, Филдинг изобрел робота для Интернета под названием MOMspider для школьного проекта. Вы можете легко сказать, что он не был типичным студентом.

После этого он придумал некоторые основные принципы разработки WWW, которые он первоначально назвал «объектной моделью HTTP», но позже переименовал ее во время работы над своей докторской диссертацией. Он решил назвать это Representational State Transfer или «REST».

REST представляет собой более легкую альтернативу SOAP. Многие разработчики сочли SOAP громоздким и сложным в использовании. REST прост для понимания , его легко написать и задокументировать. Как выразился сам Рой Филдинг: «REST изначально был создан для решения моей проблемы: как мне улучшить HTTP, не нарушая работу Интернета?»

Эта простота использования также облегчает понимание и написание приложений другими разработчиками.

REST эффективно использует полосу пропускания, поскольку он менее многословен, чем SOAP. Он поддерживает множество форматов данных, но преобладающее использование JSON означает лучшую поддержку клиентов браузера.

JSON устанавливает стандартизированный метод использования полезной нагрузки API, чтобы вы могли воспользоваться преимуществами его подключения к JavaScript и браузеру. Итак, что такое JSON и почему мы его используем?

Что такое JSON?

JSON означает нотацию объектов JavaScript и представляет собой способ представления данных, которые выглядят как объекты JavaScript.

Давайте взглянем на очень типичный объект JavaScript, который может выглядеть примерно так:

Аккуратный. Это довольно легко прочитать — наши данные хранятся в виде пар ключ-значение. Это означает, что мы можем видеть ключ слева и значение справа. Ключ остается одним и тем же для каждого объекта, но значение будет другим.

JSON повсюду в современных веб-, мобильных и IoT-приложениях. Он удобочитаемый, легкий и отлично работает с приложениями, написанными на JavaScript. Но также сравнительно легко заставить приложения, написанные на других языках, читать и генерировать его, включая Java.

Это означает, что к API, возвращающему JSON, может получить доступ приложение, написанное на Java, Ruby, Python, JS, PHP и т. д. Это делает API удобным для разработчиков, легко масштабируемым и независимым от платформы.

Благодаря поддержке разработчиков важность API начала стремительно расти, и организации начали с большим успехом их использовать. Настолько, что API стали стратегической необходимостью для бизнеса.

Кто создает эти API?

Крупные технологические компании, особенно компании, работающие в социальных сетях, часто публикуют свои совокупные данные. VK, Yandex, Google, Twitter и Slack — некоторые известные примеры компаний, которые используют API для взаимодействия.

Но дело не только в цифровых аборигенах и социальных сетях. API также поддерживаются государственными организациями, банками, организациями здравоохранения, конференциями, издательствами, программными стартапами, производственными компаниями, лигами киберспорта и даже отдельными лицами. Они делятся всем, от контента социальных сетей до простых вопросов, рейтингов, карт, текстов песен, рецептов, списков деталей и многого другого.

Говорят, что API-интерфейсы способствуют демократизации данных и, безусловно, могут вернуть людям контроль над своими данными и стать центром обслуживающих их экосистем. API-интерфейсы позволяют использовать Open Banking , Open Healthcare и в конечном итоге могут привести к « Открытому всему ».

API везде

Вот пример того, что происходит в данную интернет-минуту.

Многие из этих взаимодействий стали возможными благодаря API, что объясняет их огромную популярность в последние годы. Как я упоминал ранее, они предлагают простоту и эффективность, но пара других важных изменений в отрасли помогла повысить их популярность.

1. Во-первых, огромный рост мобильных приложений, которые часто взаимодействуют с серверными частями через Интернет.
2. Во-вторых, быстро развивающийся « Интернет вещей » (IoT) обещает обеспечить подключение к обычным устройствам, которые мы используем в повседневной жизни.

В наши дни скорость API, расширенный охват и сторонние интеграции делают их ключевыми драйверами бизнеса. Добавьте к этому их возможность настройки в соответствии с потребностями любого разработчика, и вы поймете, почему они повсюду.

Типы API

Разработка, реализация и поддержка API для Интернета имеют решающее значение для бизнес-моделей многих компаний. И один API не подходит всем. Часто используются четыре основных типа API (конечно, их больше):

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

Основные выводы

Вот что вам нужно помнить об API:

• API дают разработчику возможность сделать вызов API или «запрос» для получения информации.
• API-интерфейсы можно использовать повторно и бесконечно переделывать для создания новых приложений и сервисов.
• API-интерфейсы делают возможным быстрое подключение и покупку продуктов, таких как бронирование отеля или заказ билета в кино.
• API-интерфейсы предоставляют ключевую информацию о возможностях оперативной доставки аналитики в режиме реального времени.
• API — чрезвычайно популярный инструмент, который может ускорить ваш бизнес.

Источник: itstalker.ru

Принципы построения системных и прикладных программных интерфейсов

Операционная система всегда выступает как интерфейс между аппаратурой машины и пользователем с его задачами. Под интерфейсами операционных систем понимают специальные системные и приклад­ные программные интерфейсы, предназначенные для выполнения ниже перечисленных задач.

1. Управление процессами, которое включает в себя следующий набор основ­ных функций:

– запуск, приостановка и снятие процесса с выполнения;

– задание или изменение приоритета процесса;

– взаимодействие процессов между собой (механизмы семафоров, мьютексов и т.п.);

– удаленный вызов процедур (подпрограмм).

2. Управление памятью, которое включает в себя следующий набор основ­ных функций:

– запрос на выделение блока памяти;

– освобождение блока памяти;

– изменение параметров блока памяти (например, память может быть забло­кирована процессом либо предоставлена в общий доступ);

– отображение файлов на память (имеется не во всех системах).

3. Управление вводом-выводом, которое включает в себя запросы на управление виртуальными устройствами ввода-вывода, файловые операции (запросы к системе управления файлами на создание, изменение и удаление данных, организованных в файлы).

Выше отмечены основные наборы функций, которые выполняются ОС по соответствующим запросам от процессов. Что касается пользовательского интерфейса операционной системы, то он реализуется с помощью специальных программ­ных модулей, которые принимают его команды на соответствующем языке (воз­можно, с использованием графического интерфейса) и транслируют их в обычные вызовы в соответствии с основным интерфейсом системы. Обычно эти модули называют интерпретатором команд. Получив от пользователя команду, такой модуль после лексического и синтаксического анализа либо сам выполняет действие, либо (что случается чаще) обращается к другим модулям ОС, используя механизм прикладного программного интерфейса API.

Обращения к операционной системе в соответствии с имеющимся API может осуществляться как посредством вызова подпрограммы с передачей ей необ­ходимых параметров, так и через механизм программных прерываний. Выбор метода реализации вызовов функций API должен определяться архитектурой платформы.

В большинстве ОС используется метод вызова подпрограмм. В этом случае вызов сначала передается в модуль API (например, это может быть библиотека времени выполнения – RTL, Run Time Library), который и перенаправля­ет вызов соответствующим обработчикам программных прерываний, входящим в состав ОС. Использование механизма прерываний вызва­но, главным образом, тем, что при этом процессор переводится в режим суперви­зора.

Прикладной программный интерфейс API, как это и следует из его названия, пред­назначен для использования прикладными программами системных ресурсов ОС и реализуемых ею функций. API описывает совокупность функций и процедур, принадлежащих ядру или надстройкам ОС, и предоставляет разработчику прикладной программы набор функций, ориентированных на ор­ганизацию взаимодействия результирующей прикладной программы с так называемой «целевой вычислительной системой», которая представляет собой совокупность программных и аппаратных средств, в окружении которых выпол­няется результирующая программа. Сама результирующая программа порожда­ется системой программирования на основании кода исходной программы, соз­данного разработчиком, а также объектных модулей и библиотек, входящих в состав системы программирования. Функции API позволяют разработчику строить результирующую прикладную программу так, чтобы использовать средства целевой вычислительной системы для выполнения типовых операций. При этом разработчик программы избавлен от необходимости создания исходного кода для выполнения этих операций.

Программный интерфейс API включает в себя не только сами функции, но и со­глашения об их использовании, которые регламентируются операционной систе­мой, архитектурой целевой вычислительной системы и системой програм­мирования.

Существует несколько вариантов реализации API:

— реализация на уровне ОС;

— реализация на уровне системы программирования;

— реализация на уровне внешней библиотеки процедур и функций.

Система программирования в каждом из этих вариантов предоставляет разра­ботчику средства для подключения функций API к исходному коду программы и организации их вызовов. Объектный код функций API подключается к резуль­тирующей программе компоновщиком при необходимости.

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

В таком варианте результирующая программа обращается непосредственно к ОС. Поэтому достигается наибольшая эффективность выполнения функций API по сравнению со всеми другими вариантами реализации API. Недостатком организации API по такой схеме является практически полное от­сутствие переносимости не только кода результирующей программы, но и кода исходной программы.

Программа, созданная для одной архитектуры ВМ, не сможет исполняться на ВМ другой ар­хитектуры даже после того, как ее объектный код будет полностью перестроен. Чаще всего система программирования не сможет выполнить перестроение ис­ходного кода для новой архитектуры ВМ, поскольку мно­гие функции API, ориентированные на определенную ОС, будут в новой архи­тектуре просто отсутствовать. Таким образом, в данной схеме для переноса прикладной программы с одной це­левой вычислительной системы на другую будет требоваться изменение исход­ного кода программы.

Если функции API реализуются на уровне системы программирования, они пре­доставляются пользователю в виде библиотеки функций соответствующего язы­ка программирования (обычно речь идет о библиотеке RTL, которая включает в себя стандартные программы, поставляемые системой программирования на этапе компиляции). Эффективность функций API в таком варианте будет несколько ниже, чем при непосредственном обращении к функциям ОС, так как для выполнения многих функций API библиотека RTL языка про­граммирования должна все равно выполнять обращения к функциям ОС. Однако переносимость исходного кода программы в таком варианте будет самой высокой, поскольку синтаксис и семантика всех функций будут строго регла­ментированы в стандарте соответствующего языка программирования. Они за­висят от языка и не зависят от архитектуры целевой вычислительной системы. Поэтому для выполнения прикладной программы на новой архитектуре достаточно заново построить код результирующей програм­мы с помощью соответствующей системы программирования.

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

Причем внешняя библио­тека может быть и динамически загружаемой (то есть загружаемой во время выполне­ния программы). С точки зрения эффективности выполнения этот метод реализации API имеет самые низкие результаты, поскольку внешняя библиотека обращается как к функ­циям ОС, так и к функциям RTL языка программирования.

Только при очень высоком качестве внешней библиотеки ее эффективность становится сравнимой с библиотекой RTL. Если говорить о переносимости исходного кода, то здесь существует только одно требование – используемая внешняя библиотека должна быть доступна в любой из архитек­тур, на которые ориентирована прикладная программа. Тогда удается достигнуть переносимости. Это возможно, если используемая биб­лиотека удовлетворяет какому-то принятому стандарту, а система программиро­вания поддерживает этот стандарт.

Резюме

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

При модульном построении в ОС выделяется некоторая часть важных программных модулей, которые для более эффективной организации вычис­лительного процесса должны постоянно находиться в оперативной памяти. Эту часть ОС называют ядром операционной системы. Помимо программных модулей, входящих в состав ядра и постоянно располагающихся в оперативной памяти, может быть множество других системных программных модулей, которые загружаются в оперативную память только при необходимости, а в случае отсутствия свободного пространства могут быть замещены другими подобными модулями. Такие модули получили название транзитных или диск-резидентных.

Операционные системы прошли длительный путь развития и совершенствования своей архитектуры от монолитных систем до хорошо структурированных модульных систем, способных к развитию, расширению и легкому переносу на новые платформы. Монолитная ОС представляет собой набор процедур, каждая из которых имеет определенный интерфейс и может вызывать любую другую процедуру для выполнения некоторой нужной для нее полезной работы. При построении монолитной системы все отдельные процедуры связываются вместе в единый объектный файл.

Обобщением предыдущего подхода является организация ОС как иерархии уровней. Уровни образуются группами функций операционной системы, таких как файловая система, управление процессами и устройствами и т.п. Каждый уровень может взаимодействовать только со своим непосредственным соседом – выше- или нижележащим уровнем. Процессы передают запросы вверх и вниз по этим уровням.

Такой структурный подход также воспринимается как монолитный. На смену монолитному подходу пришла модель клиент-сервер и тесно связанная с ней концепция микроядра.

Модель клиент-сервер предполагает наличие, во-первых, программного компонента – потребителя какого-либо сервиса, то есть клиента, а во-вторых, программного компонента – поставщика этого сервиса, то есть сервера. Взаимодействие между клиентом и сервером стандартизуется, так что сервер способен обслуживать клиентов, реализованных различными способами и, может быть, разными производителями. Ядро ОС (называемое здесь микроядром), работая в привилегированном режиме, доставляет сообщение нужному серверу, сервер выполняет операцию, после чего ядро возвращает результаты клиенту с помощью другого сообщения. Подход с использованием микроядра заменил вертикальное распределение функций (в монолитных ОС) на горизонтальное.

Технология микроядер заложила основы модульных систем, способных развиваться регулярным образом. Благодаря наличию четко определенных интерфейсов возможна постепенная эволюция и расширение ОС.

Достижению целей легкой расширяемости ОС в наибольшей степени соответствует объектно-ориентированный подход, при котором каждый программный компонент является функционально изолированным от других.

Модульность операционных систем нового поколения позволяет намного легче реализовать поддержку множественных прикладных сред, которые обеспечивают совместимость (на двоичном уровне) конкретной ОС с приложениями, написанными для других ОС и процессоров.

Под интерфейсами операционных систем понимают специальные системные и приклад­ные программные интерфейсы, предназначенные для управления процессами, памятью и вводом-выводом. Для использования прикладными программами системных ресурсов ОС и реализуемых ею функций пред­назначен прикладной программный интерфейс API, который может быть реализован на уровне ОС, на уровне системы программирования или на уровне внешней библиотеки процедур и функций.

Контрольные вопросы и задания

1. Перечислите основные принципы построения операционных систем.

2. Опишите принцип модульностипостроения ОС.

3. Охарактеризуйте принцип генерируемости ОС.

4. Какие преимущества дает реализация принципа функциональной избыточности?

5. Изложите основные положения принципа виртуализации.

6. В чем заключается принцип независимости программ от внешних устройств?

7. Что дает на практике построение ОС с учетом принципа совместимости?

8. Покажите практическое значение принципа переносимости ОС.

9. Опишите принципы обеспечения безопасности.

10. Перечислите и охарактеризуйте основные структурные модели, применяемые при проектировании ОС.

11. Для выполнения каких задач предназначены системные и приклад­ные программные интерфейсы?

12. Какие возможности предоставляют разработчику программного обеспечения функции прикладного программного интерфейса?

13. Опишите основные варианты реализации функций прикладного программного интерфейса, укажите их достоинства и недостатки.

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru