Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПРОМЫШЛЕННЫХ ТЕХНОЛОГИЙ И ДИЗАЙНА

Кафедра высшей школы печати и медиатехнологии

ЭССЕ

По дисциплине «Информационные технологии»

на тему: «Рост экономики API»

Выполнила:

Андреева Вероника Константиновна

Санкт- Петербург 2021 г.



Введение

Большинство людей никогда не слышали об API, а тем более о том, что он делает. Они, вероятно, думают, что это классная новая аббревиатура, которая облегчает их переписку, например, LOL или LMAO.

Они не знают, что это мощная технология, способная достичь многого. Сегодня он используется в приложениях, которые мы используем каждый день. Такие компании, как Yelp, используют его для поиска близлежащих ресторанов. Люди все время используют API, но они даже не знают об этом. Всякий раз, когда вы хотите поделиться сообщением в блоге, статьей или рецептом и нажать на маленький значок Facebook, Twitter или LinkedIn, обычно вверху или на боковой панели, чтобы поделиться этой информацией, вы используете API.

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

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



1. Термин API

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

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

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

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

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

2. Как работает API

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

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

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

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

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

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

Этот API предоставляет доступ к данным с помощью единого и предопределенного набора операций. API REST основаны на URL-адресах и протоколе HTTP и основаны на этих 6 архитектурных ограничениях:

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

2) Единый интерфейс -- определяет интерфейс между клиентом и сервером и упрощает архитектуру, позволяя разрабатывать каждую часть отдельно.

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

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

5) Многоуровневая система -- слои расположены иерархически так, что каждый из них может "видеть" только соответствующий слой, с которым он взаимодействует.

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

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

Протокол доступа к простым объектам SOAP немного сложнее, чем REST, потому что он требует более предварительной информации о том, как он отправляет свои сообщения. Этот API существует с конца 1990-х годов и использует XML для передачи данных. Это требует строгих правил и повышенной безопасности, что требует большей пропускной способности.

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

XML-RPC -- известный как расширяемый язык разметки -- Удаленные вызовы процедур. Этот протокол использует определенный формат XML для передачи данных и является более старым и простым, чем SOAP. Клиент выполняет RPC, отправляя HTTP-запрос на сервер, реализующий XML-RPC, и получает HTTP-ответ.

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

api интерфейс программирование сигнатура

3. Типы API

Один из самых ярких примеров использования API в экономике, это операционные системы. На данный момент существует 4 самых популярных оси: Windows, MacOS, Linux, Unix. То количество приложений, цифровых сервисов и т.д., что стало возможным только благодаря внедрению технологий API поражает, а учитывая, что большинство приложений теперь кроссплатформенные, люди разных типов устройств и потребностей получают одинаковые возможности, например, приобрести товар с доставкой. Так же, стандартизации Api обеспечивает важную функциональную роль-гарантировать, что все приложения будут работать примерно на одинаковом и довольно понятном уровне. Например, программы такси будут иметь схожий интерфейс и функционал, что облегчает переход из одного сервиса в другой и увеличивает выбор конечного потребителя.

В РФ есть 2 гиганта, которые увеличивают использование API скачкообразными темпами. Это конечно СБЕР и Яндекс. Становление цифровыми гигантами, выходы на новые рынки, предложение клиентам в рамках одного сервиса всё больше количества качественных услуг-важные задачи для обоих компаний. СБЕР позиционирует главной целью создать для конечного потребителя отлаженную всеобъемлющую экосистему, для удержания пользователей и вовлечения всё новых людей.

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

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

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

В новой цифровой экономике именно взаимодействие через API обеспечивает расширение доступных компаниям данных, функциональности сервисов, причем контролируемым и организованном образом, позволяя выстраивать принципиально новые -- открытые бизнес-модели. Таких моделей множество: например, путешествия как платформа (Expedia + Airbnb), дистрибуция контрактов через партнерскую сеть (так работают американские операторы связи Vodafone и AT&T) и другие. Кроме того, создаются сложные модели кросс-привлечения клиентов, как у eBay и Best Buy.

Через использование API достигается множество различных целей, например, более быстрый выход новой компании на рынок: по данным некоторых исследователей, он может быть ускорен в 5-10 раз. Работа с третьими сторонами подключает к развитию продукта дополнительную команду, так что в этом взаимодействии могут рождаться инновационные услуги. Активация экосистемы из партнеров-провайдеров позволяет расширить дистрибуцию и вместе предоставлять клиентам лучшие на рынке цифровые персонализированные сервисы. То есть вместо того, чтобы конкурировать друг с другом -- создавать взаимовыгодные партнерства.

Так же, отдельным плюсом является возможность монетизации сервисов на базе API. Взаимодействие с другими компаниями и возможность «не отпускать» клиента со своей «орбиты», создаёт прекрасные условия для коллаборации и партнёрства с другими сервисами (например, как описанный выше пример про AIRBnB и Expedia). По данным журнала Forbes, почти 80% своей выручки Expedia генерирует именно от этого сотрудничества.

Основные модели монетизации выглядят так:

1) PAY AS YOU GO - Партнер платит за то, что использует (нет минимальной ставки)

2) TIERED PRICING - Уровень оплаты услуг зависит от уровня сервиса

3) FREEMIUM - Бесплатно до определенного лимита, все что сверху - оплачивается

4) UNIT BASED - Плата за определенные параметры / API Calls

5) TRANSACTION FEE - Оплата в процентах или по установленной ставке для количества транзакций API

6) REVENUE SHARING - Разделение выручки от продаж между партнерами

7) COST PER CLICK (CPC) - Оплата за клики пользователей, осуществленные по API

8) COST PER ACTION (CPA) - Оплата при совершении пользователями заданного действия, например, покупки

9) REFERRAL / REGISTRATION - Оплата за то, что пользователь входит в систему или регистрируется в ней через API...

Так же, отличным пример проектирования API с учётом требования потребителей может стать компания Stripe. Американская технологическая компания Stripe занимается разработкой инструментов для приема и обработки электронных платежей. Она вышла на перенасыщенный рынок платежей в 2011 г. и определила перспективный клиентский сегмент - разработчиков мобильных приложений, сосредоточившись на создании для них удобных в использовании API с платежными системами. Сейчас доля Stripe на рынке мобильных платежей составляет около 20% (и продолжает расти), стоимость компании оценивается более чем в $100 млрд. Так получилось потому, что компания поставила себя на место клиентов (в данном случае разработчиков) и задалась целью предоставить им интуитивно понятные интерфейсы, а также подготовить всю сопроводительную документацию.

Многие быстро растущие компании нередко придумывают все новые и новые продуктовые функции и только перегружают клиентов. В Stripe избежали этой проблемы, последовательно упрощая API для использования. В нетехнологическом секторе можно привести в пример Pilot Flying J, североамериканскую сеть оснащенных придорожных стоянок. Компания разработала цифровые функции (например, резервирования душевых, отслеживания парковочных мест и предоплаты горючего на заправке) и API для этих функций. Таким образом сеть смогла быстро интегрировать пакеты услуг от разных поставщиков для клиентов - водителей грузовиков. Чтобы завоевать лояльность разработчиков приложений, в которых будут созданы цифровые точки контакта с клиентами, компании должны придерживаться реализуемого API принципа «от внешнего к внутреннему».

Создание экосистем, про которое я говорил выше, можно хорошо проиллюстрировать с помощью компании Twilio. Облачная коммуникационная платформа Twilio - партнер WhatsApp, Facebook, Uber, Lyft и Airbnb. Ее основные сервисы - программируемые голосовая связь, обмен сообщениями, а также видео. Компания давно вышла на биржу, ее капитализация превысила $1 млрд. Основными продуктами, которые обеспечили ее рост, стали именно API.

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

Разработчикам приложений были нужны совместимые сервисы и глобальный охват, и Twilio стала ротвейлером массовых API для услуг связи. Как компания к этому пришла?

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

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

Компании, которые хотят выстоять и добиться успеха в цифровой экономике, должны придерживаться принципа экосистемы. Например, компания Airbus увидела проблему в авиационной отрасли, которая заключалась в том, что важная полетная и эксплуатационная информация аккумулировалась в разрозненных источниках: у авиакомпаний, производителей и сервисных предприятий. Будучи поставщиком самолетов для большинства авиакомпаний, Airbus создала для интеграции данных платформу Skywise с API. С ее помощью авиакомпаниям стало удобнее решать вопросы техобслуживания и минимизировать технические простои.

Плюс, учитывая быстроразвивающийся рынок и необходимость соответствовать требованиям нового дня перестройка функций с помощью API-важный инструмент в арсенале руководителя. Почти 20 лет назад Джефф Безос выпустил распоряжение, предписывающее всем продуктовым командам представлять используемые и создаваемые ими данные и функции через API. Мало того, он настаивал, чтобы команды и между собой обменивались информацией только через те же самые API. Так он рассчитывал добиться автономности команд и адаптивности продукта.

На закрепление потребовалось несколько лет, но это нововведение создало основу для беспрецедентного роста. В результате в Amazon перестроили взаимодействие внутренних служб и подготовили базу для запуска наиболее прибыльного на сегодня направления - коммерческого публичного облака Amazon Web Services.

Разделение функций и выделение в имеющихся информационных системах отдельных возможностей для бизнеса, которые можно реализовать через API, - важное достижение передовых цифровых компаний. API, например, помогли компании Uber оперативно освоить новый для нее сегмент доставки еды. Нетехнологическим компаниям, стремящимся идти в ногу с цифровым бизнесом, тоже важно придерживаться этого подхода. Например, когда пандемия охватила Австралию, медицинское управление Нового Южного Уэльса за две недели смогло выстроить инфраструктуру для проведения сотен тысяч тестов и пересылки результатов. Отчасти это стало возможным благодаря уже существовавшим в организации API.

В IDC прогнозируют, что в период с 2020 по 2023 г. организации вложат в цифровую трансформацию $6,8 трлн. Крупные компании могут увязать свои уже заложенные в бюджеты расходы на трансформационные программы с созданием новых бизнес-возможностей с помощью API.

И вхождение в API-экономику не обязательно обойдется дорого. В ряде отраслей применяются нормативы и стандарты, касающиеся использования API, например платежная директива PSD2 на рынке финансовых услуг, стандарт обмена медицинской информацией FHIR в здравоохранении, концепция открытых интерфейсов Open APIs от TM Forum для телекоммуникационных услуг и т. д. Компании из этих отраслей могут сэкономить благодаря тому, что все предприятия отрасли обязаны соблюдать эти предписания.

Главное преимущество в работе с цифровыми решениями состоит в том, что не нужно разбирать старую конструкцию и строить новую.

Лучший первый шаг в использовании API - действовать понемногу и постепенно. Соберите небольшую многопрофильную команду экспертов по коммерческим и техническим вопросам. Затем проанализируйте потребности клиентов и оцените цифровые возможности. Мыслите в масштабах экосистемы и определите целевую бизнес-модель и внешние взаимосвязи с партнерами. Наконец, сформируйте на основе API набор функций и инфраструктуру, необходимые для создания инновационных решений. Измеряйте, анализируйте и повторяйте цикл сначала. Этот подход позволяет организациям осуществлять инновации с небольшими рисками и небольшими чистыми издержками. Из стартовых инвестиций требуется разве что финансирование для команды и деньги на связанную с API инфраструктуру. Их, вероятно, можно изыскать в рамках имеющихся бюджетов программ цифровой трансформации. Расходы можно наращивать по мере получаемого коммерческого эффекта, и это позволит команде избежать поспешных и слишком резких шагов.

Каталог ProgrammableWeb насчитывал цифру в 17 000 API в первом квартале 2017 года. Это означает, что вы вполне способны построить бизнес с нуля с помощью API. У вас есть инструменты, ингредиенты и все, что вам нужно сейчас, это «Секретный рецепт», чтобы объединить их и продать.

Экономика API вращается вокруг более точной формы «Программное обеспечение как услуга» (SaaS) и «API как услуга» (AaaS). В настоящее время программное обеспечение как услуга создает взаимодействие между пользователями, а API как услуга предоставляется для взаимодействия программного обеспечения в Интернете. Таким образом, давая вам широкий выбор вариантов на выбор. API вступает в новую эру обслуживания B2B (*business to business) с помощью «фиксируемых гаек и болтов», которые вписываются сразу.

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

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

Если рассмотреть, как пример банковскую сферу (тот же СБЕР, который упоминался выше), то одним из локомотивов внедрения API является Barclays банк. В первую очередь для банковского сектора это возможность создать универсальное мобильное приложение, в котором пользователи видят всю необходимою информацию о банке, которым пользуются и о своих активах и возможностях в нём. Мульти-банковское приложение позволяет:

· Видеть свой баланс онлайн и удобно управлять своими счетами в разных банках.

· Упростить торговые операции (выбор банка для платежа, быстрая проверка кредитоспособности, проведение оплаты с приложения).

· Воплотить ипотечные/кредитные приложения, которые могут подтверждать платежеспособность граждан с мобильного устройства, упрощать процесс получения ипотеки/кредита.

В странах Европейского Союза с января 2018 года действует стандарт PSD 2 (Европейская платежная директива), которая обязывает банки предоставлять клиентские базы данных и программные интерфейсы (API) для 3-их лиц, собирающихся работать в финансовом секторе. Таким образом, планируется усилить конкуренцию на рынке мобильных онлайн-платежей за счет выхода на рынок технологических компаний.

В США государственное регулирование вопроса открытых API банков отсутствует. Тем не менее, благоприятная финансовая обстановка привела к созданию банковского агрегатора компании Mint, сайтом которой уже в 2016 году пользовались около 20 млн. жителей США и Канады.В Сингапуре денежно-кредитное управление (MAS) поддерживает принципы открытого банковского API. Ассоциация банков Сингапура (ABS) и MAS подготовили документ Finance-as-a-Service: API Playbook, содержащий информацию и рекомендации для финансового сектора и призванный обеспечить эффективный обмен финансовой информацией, а также создать почву для запуска инновационных банковских проектов.В Индии была создана информационная платформа открытых API India Stack, которая включает в себя такие системы и сервисы, как: Aadhaar - крупнейшую в мире систему цифровой биометрической идентификации; Национальная платежная корпорация Индии; Digital locker - платформа для формирования и верификации документов в цифровом виде и др.IndiaStack позволяет разработчикам и технологическим сатрапам выходить на рынок мобильных приложений по идентификации и аутентификации пользователей финансовых услуг.

В России в 2016 году по инициативе Сбербанка, Альфа-банка и других финансовых компаний была создана организация ФинТех, целью которой является развитие финансовых технологий в стране. Также в России развивается ФинтехСмарт -- ассоциация-профсоюз, занимающаяся развитием среды для финансовых стартапов и сообщество RusFinTech, организующее семинары и конференции на тему финансовых технологий.

Говоря о перспективах развития открытых банковских API в России, стоит упомянуть инициативу, запущенную Банком России совместно с финтех организациями.

Данное направление предполагает проработку сценариев применения открытых API, проведение пилотных проектов, а также разработку стандартов и документов по применению открытых API в России. Уже сейчас крупнейшие банки страны, такие как Сбербанк, Альфа-Банк, ВТБ 24, Газпромбанк и Банк Открытие готовы предоставить свои API сторонним организациям.

Тенденции развития открытых банковских API говорят о том, что направление по разработке мобильных приложений для бизнеса финтех организаций, а именно -- мульти-банковских приложений в России станет актуальным в ближайшее время. По данным исследовательского агентства Markswebb, на территории РФ мобильными банками пользуются 18 млн человек, что составляет около 33% от общей интернет-аудитории страны. Хотя бы одним интернет-банком пользуются 35,3 млн человек, или 64,5% всех российских интернет-пользователей. Возраст пользователей интернет и мобильного банкинга ранжируется от 18 до 64 лет.

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

Опыт Wellsoft в разработке мобильных приложений для банков позволяет реализовывать подобные решения в данный момент при желании клиента.

4. Сигнатура функции

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

Иногда различают сигнатуру вызова и сигнатуру реализации функции. Сигнатура вызова обычно составляется по синтаксической конструкции вызова функции с учётом сигнатуры области видимости данной функции, имени функции, последовательности фактических типов аргументов в вызове и типе результата. В сигнатуре реализации обычно участвуют некоторые элементы из синтаксической конструкции объявления функции: спецификатор области видимости функции, её имя и последовательность формальных типов аргументов.

Например, в языке программирования C++ (C++ (читается си-плюс-плюс) - компилируемый, статически типизированный язык программирования общего назначения.) простая функция однозначно опознаётся компилятором по её имени и последовательности типов её аргументов, что составляет сигнатуру функции в этом языке. Если функция является методом некоторого класса, то в сигнатуре будет участвовать и имя класса.

В языке программирования Java (Java - строго типизированный объектно-ориентированный язык программирования общего назначения, разработанный компанией Sun Microsystems (в последующем приобретённой компанией Oracle). Разработка ведётся сообществом, организованным через Java Community Process; язык и основные реализующие его технологии распространяются по лицензии GPL. Права на торговую марку принадлежат корпорации Oracle.) сигнатуру метода составляет его имя и последовательность типов параметров; тип возвращаемого значения в сигнатуре не участвует.

5. История создания Java

Изначально язык назывался Oak («Дуб»), разрабатывался Джеймсом Гослингом для программирования бытовых электронных устройств. Из-за того, что язык с таким названием уже существовал, Oak был переименован в Java. Назван в честь марки кофе Java, которая, в свою очередь, получила наименование одноимённого острова (Ява), поэтому на официальной эмблеме языка изображена чашка с горячим кофе. Существует и другая версия происхождения названия языка, связанная с аллюзией на кофе-машину как пример бытового устройства, для программирования которого изначально язык создавался. В соответствии с этимологией в русскоязычной литературе с конца двадцатого и до первых лет двадцать первого века название языка нередко переводилось как Ява, а не транскрибировалось.

В результате работы проекта мир увидел принципиально новое устройство, карманный персональный компьютер Star7, который опередил своё время более чем на 10 лет, но из-за большой стоимости в 50 долларов не смог произвести переворот в мире технологии и был забыт.

Устройство Star7 не пользовалось популярностью, в отличие от языка программирования Java и его окружения. Следующим этапом жизни языка стала разработка интерактивного телевидения. В 1994 году стало очевидным, что интерактивное телевидение было ошибкой.

С середины 1990-х годов язык стал широко использоваться для написания клиентских приложений и серверного программного обеспечения. Тогда же определённое распространение получила технология Java-апплетов -- графических Java-приложений, встраиваемых в веб-страницы; с развитием возможностей динамических веб-страниц в 2000-е годы технология стала применяться редко.

В веб-разработке применяется Spring Framework; для документирования используется утилита Javadoc.

6. Семантика функции

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

API операционных систем. Проблемы, связанные с многообразием API

Практически все операционные системы (UNIX, Windows, OS X, Linux и т. д.) имеют API, с помощью которого программисты могут создавать приложения для этой операционной системы. Главный API операционных систем -- это множество системных вызовов.

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

С другой стороны, отличия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности -- написание «промежуточных» API (API графических интерфейсов wxWidgets, GTK и т. п.), написание библиотек, которые отображают системные вызовы одной ОС в системные вызовы другой ОС (такие среды исполнения, как Wine, cygwin и т. п.), введение стандартов кодирования в языках программирования (например, стандартная библиотека языка C), написание интерпретируемых языков, реализуемых на разных платформах (sh, Python, Perl, PHP, Tcl, Javascript, Ruby и т. д.).

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

Например:

Для того, чтобы увидеть в браузере строчку «Hello, world!», достаточно лишь создать HTML-документ с минимальным заголовком и простейшим телом, содержащим данную строку. Когда браузер откроет этот документ, программа-браузер передаст имя файла (или уже открытый дескриптор файла) библиотеке, обрабатывающей HTML-документы, та, в свою очередь, при помощи API операционной системы прочитает этот файл и разберётся в его устройстве, затем последовательно вызовет через API библиотеки стандартных графических примитивов операции типа «очистить окошко», «написать „Hello, world!“ выбранным шрифтом». Во время выполнения этих операций библиотека графических примитивов обратится к библиотеке оконного интерфейса с соответствующими запросами, уже эта библиотека обратится к API операционной системы, чтобы записать данные в буфер видеокарты.

При этом практически на каждом из уровней реально существует несколько возможных альтернативных API. Например: мы могли бы писать исходный документ не на HTML, а на LaTeX, для отображения могли бы использовать любой браузер. К тому же различные браузеры используют различные HTML-библиотеки, и, кроме того, всё это может быть собрано с использованием различных библиотек примитивов и на различных операционных системах.

Основными сложностями существующих многоуровневых систем API, таким образом, являются:

Сложность портирования программного кода с одной системы API на другую (например, при смене ОС);

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

Применение API в повседневной жизни.

1. Google Календарь.

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

2. Заказ авиабилетов.

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

3. Навигация на сайтах и в приложениях.

Крупные компании, в том числе Apple, Google, «Яндекс» и другие, разработали API, позволяющие подключить собственный картографический сервис к другим площадкам. Так, в «Яндекс.Карты» встроены сервисы «Транспорт» и «Пробки». Многие приложения на Android, например, по доставке еды или для спорта, используют встроенный в ОС API, чтобы подключить карты Google к своему сервису. На iOS аналогичная ситуация с Apple Maps.

4. Кнопки авторизации.

На многих сайтах есть кнопки, позволяющие зарегистрироваться через уже существующие аккаунты на популярных площадках и в соцсетях. Это возможно благодаря API, которые есть у Google, Facebook, Apple, Twitter, «ВКонтакте» и других компаний.

5. Протоколы 3D преобразования.

С помощью протоколов а-ля OpenGL производительность и красота изображений, выводимых устройствами обычного пользователя, улучшается с каждым днём и добавляет всё новые грани впечатлений и возможностей пользователю.

6. Приложения вызова такси\курьеров\каршеринга.

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



Заключение

АPI существует уже довольно продолжительный отрезок времени, при этом не только не устаревая, но и развиваясь «в ногу со временем», предлагая обоим сторонам большой функционал возможностей.

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

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



Источники

1. Harvard Business Review Россия от 22.04.21

Размещено на Allbest.ru

...