API — Википедия

✋ Ответ на вопрос №66419: Интерфейс прикладной программы обеспечивает…

Похожие вопросы

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

загрузку прикладной программы в оперативную память

связь прикладной программы с процессором

загрузку прикладной программы во внешнюю память

связь прикладной программы с другими программами

связь прикладной программы с пользователем

Операционная система НЕ обеспечивает интерфейс между

программным и аппаратным обеспечением

разными видами программного обеспечения

пользователем и программными средствами

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

разными компьютерами.

Установите соответствие между видами интерфейса и их назначениями.
1. Интерфейс пользователя
2. Аппаратно-программный интерфейс
3. Программный интерфейс

организация работы в прикладных программах

взаимодействие между пользователем и программно-аппаратными средствами компьютера

связь между программным и аппаратным обеспечением компьютера

взаимодействие между разными видами программного обеспечения

Установите соответствие между видами интерфейса и их назначениями.
1. Интерфейс пользователя
2. Аппаратно-программный интерфейс
3. Программный интерфейс

организация работы в прикладных программах

взаимодействие между пользователем и программно-аппаратными средствами компьютера

связь между программным и аппаратным обеспечением компьютера

взаимодействие между разными видами программного обеспечения

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

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

034_0_1.jpg

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

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

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

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

Цель

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

API как средство интеграции приложений[править | править код]

API определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.

Если программу (модуль, библиотеку) рассматривать как чёрный ящик, то API — это множество «ручек», которые доступны пользователю данного ящика и которые он может вертеть и дёргать.

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

По такому принципу построены протоколы передачи данных по Интернету. Стандартный стек протоколов (сетевая модель OSI) содержит 7 уровней (от физического уровня передачи бит до уровня протоколов приложений, подобных протоколам HTTP и IMAP). Каждый уровень пользуется функциональностью предыдущего («нижележащего») уровня передачи данных и, в свою очередь, предоставляет нужную функциональность следующему («вышележащему») уровню.

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

API библиотеки функций и классов включает в себя описание сигнатур и семантики функций.

Сигнатура функции[править | править код]

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

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

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

В языке программирования Java сигнатуру метода составляет его имя и последовательность типов параметров; тип возвращаемого значения в сигнатуре не участвует.[5]

Семантика функции[править | править код]

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

История термина

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

прикладных программ

.

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

Идея API намного старше термина. Британские ученые-компьютерщики Уилкс и Уиллер в 1940-х годах работали над модульными библиотеками программного обеспечения для компьютера EDSAC . Джошуа Блох утверждает, что Уилкс и Уиллер «скрыто изобрели» API, потому что это скорее открытая концепция, чем изобретенная.

Термин «интерфейс прикладной программы» (без суффикса -ing ) впервые был записан в статье под названием Структуры данных и методы удаленной компьютерной графики, представленной на конференции AFIPS в 1968 году. Авторы этой статьи используют этот термин для описания взаимодействия приложение – в данном случае графическая программа – с остальной частью компьютерной системы. Согласованный интерфейс приложения (состоящий из вызовов подпрограмм Fortran ) был предназначен для того, чтобы освободить программиста от работы с особенностями устройства графического отображения и обеспечить независимость от оборудования в случае замены компьютера или дисплея.

Термин был введен в области баз данных по CJ Дата в 1974 статье под названием реляционная и сети Подходы: Сравнение Application Programming Interface . API стал частью структуры ANSI / SPARC для систем управления базами данных . Эта структура обрабатывала интерфейс прикладного программирования отдельно от других интерфейсов, таких как интерфейс запросов. Специалисты по базам данных в 1970-х годах заметили, что эти разные интерфейсы можно комбинировать; достаточно богатый интерфейс приложения может поддерживать и другие интерфейсы.

Это наблюдение привело к созданию API, поддерживающих все типы программирования, а не только прикладное программирование. К 1990 году технолог Карл Маламуд определил API просто как «набор сервисов, доступных программисту для выполнения определенных задач» .

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

Веб-API теперь является наиболее распространенным значением термина API. При таком использовании термин «API» в некоторой степени перекликается с терминами « протокол связи» и « удаленный вызов процедуры» .

API операционных систем. Проблемы, связанные с многообразием API[править | править код]

Практически все операционные системы (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, таким образом, являются:

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

использование

Библиотеки и фреймворки

API обычно связан с программной библиотекой . API описывает и предписывает «ожидаемое поведение» (спецификацию), в то время как библиотека является «фактической реализацией» этого набора правил.

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

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

Использование API может варьироваться в зависимости от типа используемого языка программирования. API для процедурного языка, такого как Lua, может состоять в основном из базовых подпрограмм для выполнения кода, манипулирования данными или обработки ошибок, в то время как API для объектно-ориентированного языка , такого как Java, предоставит спецификацию классов и их методов класса .

Привязки языков также являются API. Путем сопоставления функций и возможностей одного языка интерфейсу, реализованному на другом языке, языковая привязка позволяет использовать библиотеку или службу, написанную на одном языке, при разработке на другом языке. Такие инструменты, как SWIG и F2PY, генератор интерфейсов Fortran- to- Python , облегчают создание таких интерфейсов.

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

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

Операционные системы

API может определять интерфейс между приложением и операционной системой . 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

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

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

Модификация прокси-объекта также приведет к соответствующей модификации удаленного объекта.

Веб-API

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

При использовании в контексте веб-разработки API обычно определяется как набор спецификаций, таких как сообщения запроса протокола передачи гипертекста (HTTP), вместе с определением структуры сообщений ответа, обычно на расширяемом языке разметки ( XML ) или в формате JavaScript Object Notation ( JSON ). Примером может служить API транспортной компании, который можно добавить на веб-сайт, ориентированный на электронную коммерцию, чтобы упростить заказ услуг доставки и автоматически включать текущие тарифы на доставку, при этом разработчику сайта не нужно вводить таблицу тарифов грузоотправителя в веб-базу данных. В то время как «веб-API» исторически был практически синонимом веб-службы , недавняя тенденция (так называемая Веб 2.0 ) заключалась в отходе от веб-служб на основе простого протокола доступа к объектам ( SOAP ) и сервис-ориентированной архитектуры (SOA) в сторону более прямой веб-ресурсы в стиле передачи репрезентативного состояния (REST) и ресурсо-ориентированная архитектура (ROA). Частично эта тенденция связана с движением семантической паутины к Resource Description Framework (RDF), концепции продвижения технологий разработки онтологий на основе Интернета . Веб-API-интерфейсы позволяют комбинировать несколько API-интерфейсов в новые приложения, известные как гибридные приложения . В пространстве социальных сетей веб-API позволили веб-сообществам облегчить обмен контентом и данными между сообществами и приложениями. Таким образом, контент, который динамически создается в одном месте, можно публиковать и обновлять в нескольких местах в Интернете. Например, REST API Twitter позволяет разработчикам получать доступ к основным данным Twitter, а Search API предоставляет разработчикам методы взаимодействия с данными поиска Twitter и тенденциями.

Дизайн

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

Наиболее известные API[править | править код]

Список примеров в этом разделе не основывается на авторитетных источниках, посвящённых непосредственно предмету статьи или её раздела.

Добавьте

ссылки на источники

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

Операционных системГрафических интерфейсовЗвуковых интерфейсовАутентификационных систем

Web API[править | править код]

Используется в веб-разработке — содержит, как правило, определённый набор HTTP-запросов, а также определение структуры HTTP-ответов, для выражения которых используют XML− или JSON−формат.

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

Примеры:MediaWiki API

Политика выпуска

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

Основные правила выпуска API:

  • Частный : API предназначен только для внутреннего использования компанией.
  • Партнер : API могут использовать только определенные деловые партнеры. Например, компании по аренде автомобилей, такие как Uber и Lyft, позволяют утвержденным сторонним разработчикам напрямую заказывать поездки из своих приложений. Это позволяет компаниям осуществлять контроль качества, определяя, какие приложения имеют доступ к API, и обеспечивает им дополнительный поток доходов.
  • Общедоступный : API доступен для публичного использования. Например, Microsoft делает Windows API общедоступным, а Apple выпускает свой API Cocoa , чтобы программное обеспечение можно было писать для их платформ . Не все общедоступные API доступны для всех. Например, интернет-провайдеры, такие как Cloudflare или Voxility, используют RESTful API, чтобы позволить клиентам и торговым посредникам получать доступ к информации об их инфраструктуре, статистике DDoS, производительности сети или элементам управления панелью управления. Доступ к таким API предоставляется либо с помощью «токенов API», либо с помощью проверки статуса клиента.

Последствия для публичного API

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

Когда части публично представленного API могут быть изменены и, следовательно, нестабильны, такие части конкретного API должны быть явно задокументированы как «нестабильные». Например, в библиотеке Google Guava части, которые считаются нестабильными и которые могут скоро измениться, отмечены аннотацией Java @Beta .

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

Клиентский код может содержать новаторские или гибкие способы использования, которые не были предусмотрены разработчиками API. Другими словами, для библиотеки со значительной пользовательской базой, когда элемент становится частью общедоступного API, его можно использовать по-разному. 19 февраля 2020 года Akamai опубликовала свой ежегодный отчет «Состояние Интернета», демонстрирующий растущую тенденцию киберпреступников, нацеленных на публичные платформы API в финансовых сервисах по всему миру. С декабря 2017 года по ноябрь 2019 года Akamai стал свидетелем 85,42 миллиарда атак с нарушением учетных данных. Около 20%, или 16,55 миллиарда, были против имен хостов, определенных как конечные точки API. Из них 473,5 миллиона адресованы организациям сектора финансовых услуг.

См. также[править | править код]

  • Двоичный интерфейс приложений
  • Абстрактный тип данных
  • Повторное использование кода

Документация

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

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

Традиционные файлы документации часто представлены через систему документации, такую ​​как Javadoc или Pydoc, которая имеет единообразный внешний вид и структуру. Однако типы содержимого, включенного в документацию, различаются от API к API.

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

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

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

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

Споры об авторских правах

В 2010 году корпорация Oracle подала в суд на Google за распространение новой реализации Java, встроенной в операционную систему Android. Google не получил разрешения на воспроизведение Java API, хотя разрешение было дано аналогичному проекту OpenJDK. Судья Уильям Алсуп постановил в деле Oracle против Google, что API-интерфейсы не могут быть защищены авторским правом в США и что победа Oracle значительно расширила бы защиту авторских прав и позволила бы охранять авторские права на простые программные команды:

Принять заявление Oracle означало бы разрешить кому-либо создать авторское право на одну версию кода для выполнения системы команд и тем самым запретить всем остальным писать ее разные версии для выполнения всех или части одних и тех же команд.

Однако в 2014 году решение Алсупа было отменено при подаче апелляции в Апелляционный суд Федерального округа , хотя вопрос о том, является ли такое использование API добросовестным, остался нерешенным.

В 2016 году после двухнедельного судебного разбирательства жюри решило, что повторная реализация Google API Java является добросовестным использованием, но Oracle пообещала обжаловать это решение. Oracle выиграла апелляцию, поскольку Апелляционный суд Федерального округа постановил, что использование API Google не соответствует критериям добросовестного использования. В 2019 году Google подал апелляцию в Верховный суд США по поводу постановлений о защите авторских прав и добросовестного использования, и Верховный суд удовлетворил требования.

дальнейшее чтение

  • Тайна Бучер (16 ноября 2013 г.). «Объекты интенсивного переживания: случай API Twitter» . Вычислительная культура (3). ISSN   2047-2390 . Утверждает, что «API – это далеко не нейтральные инструменты» и составляют ключевую часть современного программирования, понимаемую как фундаментальную часть культуры.
Рейтинг
( 1 оценка, среднее 5 из 5 )
Загрузка ...