Conexão entre computadores ou entre programas de computador
Uma API no contexto de uma rede de computadores
Uma interface de programação de aplicações (API, do inglêsapplication programming interface) é uma conexão entre computadores ou entre programas de computador. É um tipo de interface de software que oferece um serviço a outras partes de software. Um documento ou padrão que descreve como construir essa conexão ou interface é chamado de especificação de API. Diz-se que um sistema computacional que atende a esse padrão implementa ou expõe uma API. O termo API pode referir-se tanto à especificação quanto à implementação.
Ao contrário de uma interface do usuário, que conecta um computador a uma pessoa, uma interface de programação de aplicações conecta computadores ou partes de software entre si. Ela não se destina a ser usada diretamente por uma pessoa (o usuário final), a não ser por um programador que a esteja incorporando a um software. Uma API costuma ser composta de diferentes partes, que funcionam como ferramentas ou serviços disponíveis para o programador. Diz-se que um programa ou programador que usa uma dessas partes chama essa porção da API. As chamadas que compõem a API também são conhecidas como sub-rotinas, métodos, requisições ou endpoints. Uma especificação de API define essas chamadas, isto é, explica como usá-las ou implementá-las.
Um dos principais propósitos das APIs é ocultar os detalhes internos do funcionamento de um sistema, expondo apenas as partes que um programador considerará úteis e mantendo-as consistentes mesmo que os detalhes internos mudem posteriormente. Uma API pode ser feita sob medida para um par específico de sistemas ou ser um padrão compartilhado que permite a interoperabilidade entre muitos sistemas.
Uma API abre um sistema de software a interações vindas de fora. Ela permite que dois sistemas de software se comuniquem através de uma fronteira — uma interface — usando sinais mutuamente acordados. Em outras palavras, uma API conecta entidades de software. Ao contrário de uma interface do usuário, uma API normalmente não é visível para os usuários: ela é uma parte "dos bastidores" de um sistema de software, usada para a comunicação entre máquinas.
Uma API bem projetada expõe apenas os objetos ou as ações de que o software ou os desenvolvedores de software precisam e oculta os detalhes que não têm utilidade. Essa abstração simplifica a programação.
Metaforicamente, as APIs conectam software como blocos de encaixar.
A construção de software com APIs já foi comparada ao uso de brinquedos de blocos de montar, como os blocos Lego. Os serviços ou as bibliotecas de software são análogos aos blocos: podem ser unidos por meio de suas APIs, compondo um novo produto de software.:Prefácio O processo de união é chamado de integração.
Como exemplo, considere um sensor meteorológico que oferece uma API. Quando determinada mensagem é transmitida ao sensor, ele detecta as condições meteorológicas do momento e responde com um boletim meteorológico. A mensagem que ativa o sensor é uma chamada de API, e o boletim é uma resposta da API. Um aplicativo de previsão do tempo poderia integrar-se a várias APIs de sensores meteorológicos, reunindo dados de toda uma área geográfica.
Uma API é frequentemente comparada a um contrato. Ela representa um acordo entre partes: um provedor de serviço, que oferece a API, e os desenvolvedores de software, que dependem dela. Se a API permanecer estável, ou se mudar apenas de maneiras previsíveis, a confiança dos desenvolvedores na API aumentará, o que pode aumentar o uso que fazem dela.
História do termo
Diagrama que mostra uma ideia dos participantes de um workshop realizado em 1978: a API do sistema de gerenciamento de banco de dados (SGBD) poderia ser expandida para servir de base a outros tipos de interfaces de banco de dados, além dos programas aplicativos. O relatório do workshop foi publicado pelo National Bureau of Standards em 1981.
O termo API descrevia inicialmente uma interface apenas para programas voltados ao usuário final, conhecidos como programas aplicativos. Essa origem ainda se reflete no nome "interface de programação de aplicações". Hoje, o termo é mais amplo e inclui também software utilitário e até interfaces de hardware.
A ideia de API é muito mais antiga que o próprio termo. Os cientistas da computação britânicos Maurice Wilkes e David Wheeler trabalharam, na década de 1940, em uma biblioteca de software modular para o EDSAC, um dos primeiros computadores. As sub-rotinas dessa biblioteca eram armazenadas em fita de papel perfurada, organizada em um arquivo de gavetas. Esse arquivo também continha o que Wilkes e Wheeler chamaram de "catálogo da biblioteca", com anotações sobre cada sub-rotina e sobre como incorporá-la a um programa. Hoje, esse catálogo seria chamado de API (ou especificação ou documentação de API), porque instrui o programador sobre como usar cada sub-rotina de que ele precisa.
O livro de Wilkes e Wheeler The Preparation of Programs for an Electronic Digital Computer contém a primeira especificação de API publicada. Joshua Bloch considera que Wilkes e Wheeler "inventaram latentemente" a API, porque ela é mais um conceito descoberto do que inventado.
Embora as pessoas que cunharam o termo API estivessem implementando software em um Univac 1108, o objetivo de sua API era tornar possíveis programas independentes de hardware.
O termo application program interface (sem o sufixo -ing de programming) foi registrado pela primeira vez em um artigo intitulado Data structures and techniques for remote computer graphics ("Estruturas de dados e técnicas para computação gráfica remota"), apresentado em uma conferência da AFIPS em 1968. Os autores desse artigo usam o termo para descrever a interação de uma aplicação — neste caso, um programa gráfico — com o restante do sistema computacional. Uma interface de aplicação consistente (composta de chamadas de sub-rotinas em Fortran) tinha o objetivo de livrar o programador de lidar com as idiossincrasias do dispositivo de exibição gráfica e de proporcionar independência de hardware caso o computador ou o monitor fossem substituídos.
Segundo o próprio C. J. Date, foi ele quem introduziu o termo no campo dos bancos de dados, em um artigo de 1974 intitulado The Relational and Network Approaches: Comparison of the Application Programming Interfaces ("As abordagens relacional e em rede: comparação das interfaces de programação de aplicações"). A API tornou-se parte da arquitetura ANSI/SPARC para sistemas de gerenciamento de banco de dados. Essa arquitetura tratava a interface de programação de aplicações separadamente de outras interfaces, como a interface de consulta. Na década de 1970, profissionais de banco de dados observaram que essas diferentes interfaces podiam ser combinadas: uma interface de aplicação suficientemente rica poderia dar suporte também às demais.
Essa observação levou a APIs que davam suporte a todos os tipos de programação, e não apenas à programação de aplicações. Em 1990, o tecnólogo Carl Malamud definia a API simplesmente como "um conjunto de serviços disponíveis a um programador para executar determinadas tarefas".
Captura de tela da documentação de uma API web escrita pela NASA
A ideia de API foi ampliada novamente com o advento das chamadas de procedimento remoto e das APIs web. À medida que as redes de computadores se tornaram comuns nas décadas de 1970 e 1980, os programadores passaram a querer chamar bibliotecas localizadas não apenas em seus computadores locais, mas também em computadores situados em outros lugares. Essas chamadas de procedimento remoto eram bem suportadas, em particular, pela linguagem Java. Na década de 1990, com a difusão da internet, padrões como CORBA, COM e DCOM competiram para se tornar a forma mais comum de expor serviços de API.
A tese de doutorado de Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures, apresentada na Universidade da Califórnia em Irvine em 2000, delineou a transferência de estado representacional (REST) e descreveu a ideia de uma "interface de programação de aplicações baseada em rede", que Fielding contrastou com as APIs tradicionais "baseadas em bibliotecas". As APIs web baseadas em XML e JSON passaram a ter ampla adoção comercial a partir de 2000, e a API web é hoje o significado mais comum do termo API.
A Web semântica, proposta por Tim Berners-Lee em 2001, incluía "APIs semânticas", que reformulavam a API como uma interface de dados aberta e distribuída, e não como uma interface de comportamento de software. Interfaces e agentes proprietários tornaram-se mais difundidos que os abertos, mas a ideia da API como interface de dados se consolidou. Como as APIs web são amplamente usadas para trocar dados de todos os tipos on-line, API tornou-se um termo amplo, que descreve grande parte da comunicação na internet. Usado dessa forma, o termo API tem significado parcialmente sobreposto ao do termo protocolo de comunicação.
Tipos
Bibliotecas e frameworks
A interface de uma biblioteca de software é um tipo de API. A API descreve e prescreve o "comportamento esperado" (uma especificação), enquanto a biblioteca é uma "implementação real" desse conjunto de regras.
Uma mesma API pode ter várias implementações (ou nenhuma, se for abstrata), na forma de diferentes bibliotecas que compartilham a mesma interface de programação.
A separação entre a API e sua implementação pode permitir que programas escritos em uma linguagem usem uma biblioteca escrita em outra. Por exemplo, como Scala e Java são compiladas para bytecode compatível, os desenvolvedores de Scala podem aproveitar qualquer API Java.
O uso de uma API pode variar conforme o tipo de linguagem de programação envolvida. Uma API para uma linguagem procedimental, como Lua, pode consistir principalmente em rotinas básicas para executar código, manipular dados ou tratar erros, enquanto uma API para uma linguagem orientada a objetos, como Java, fornece uma especificação de classes e de seus métodos. A lei de Hyrum afirma que "com um número suficiente de usuários de uma API, não importa o que se promete no contrato: todos os comportamentos observáveis do sistema passarão a ser usados como dependência por alguém". Por outro lado, estudos indicam que a maioria das aplicações que usam uma API utiliza apenas uma pequena parte dela.
As vinculações de linguagem (language bindings) também são APIs. Ao mapear os recursos e as capacidades de uma linguagem para uma interface implementada em outra, uma vinculação de linguagem permite que uma biblioteca ou serviço escrito em uma linguagem seja usado no desenvolvimento em outra. Ferramentas como o SWIG e o F2PY, um gerador de interfaces entre Fortran e Python, facilitam a criação dessas interfaces.
Uma API também pode estar relacionada a um framework de software: um framework pode basear-se em várias bibliotecas que implementam diversas APIs, mas, ao contrário do uso normal de uma API, o acesso ao comportamento incorporado ao framework é mediado pela extensão de seu conteúdo com novas classes acopladas ao próprio framework.
Além disso, o fluxo de controle geral do programa pode ficar fora do controle de quem faz a chamada e nas mãos do framework, por meio de inversão de controle ou de um mecanismo semelhante.
Sistemas operacionais
Uma API pode especificar a interface entre uma aplicação e o sistema operacional. O POSIX, por exemplo, especifica um conjunto de APIs comuns que visam permitir que uma aplicação escrita para um sistema operacional compatível com POSIX seja compilada para outro sistema operacional compatível com POSIX.
A Microsoft tem procurado manter a compatibilidade retroativa de suas APIs, em particular da API do Windows (Win32), de modo que aplicações mais antigas podem ser executadas em versões mais novas do Windows por meio de uma configuração específica de cada executável, chamada "modo de compatibilidade". Não está claro em que medida o acesso dos desenvolvedores da Microsoft às APIs internas dos sistemas operacionais da empresa representa uma vantagem. Em 1987, Richard A. Shaffer, do Technologic Computer Letter, comparou a situação a um jogo de beisebol em que "a Microsoft é dona de todos os tacos e do campo", e grandes fornecedores, como a Lotus Development e a Ashton-Tate, teriam recebido informações sobre a próxima versão do MS-DOS que os desenvolvedores de software menores não receberam. Ed Esber, da Ashton-Tate, disse em uma entrevista de 1987, no entanto, que Bill Gates lhe contara que seus desenvolvedores às vezes precisavam reescrever software baseado em versões preliminares de APIs. Gates observou na entrevista que os aplicativos da Microsoft para o Macintosh eram mais bem-sucedidos que os feitos para o MS-DOS, porque a empresa não precisava dedicar recursos também ao Mac OS.
As APIs remotas permitem que os desenvolvedores manipulem recursos remotos por meio de protocolos, padrões específicos de comunicação que permitem que diferentes tecnologias funcionem em conjunto, independentemente de linguagem ou plataforma. Por exemplo, a API Java Database Connectivity permite que os desenvolvedores consultem muitos tipos diferentes de bancos de dados com o mesmo conjunto de funções, enquanto a API Java Remote Method Invocation permite a invocação de funções que operam remotamente, mas que parecem locais para o desenvolvedor.
Assim, as APIs remotas são úteis para manter a abstração de objetos na programação orientada a objetos: uma chamada de método executada localmente em um objeto proxy invoca o método correspondente no objeto remoto, usando o protocolo de comunicação remota, e obtém o resultado para ser usado localmente como valor de retorno. Desse modo, as operações feitas sobre o objeto proxy refletem-se no objeto remoto.
No contexto do desenvolvimento web, uma API é normalmente definida como um conjunto de especificações, como as mensagens de requisição do Hypertext Transfer Protocol (HTTP), acompanhado de uma definição da estrutura das mensagens de resposta, geralmente no formato XML (Extensible Markup Language) ou JSON (JavaScript Object Notation). Um exemplo seria a API de uma transportadora que pode ser adicionada a um site de comércio eletrônico para facilitar a contratação de serviços de envio e incluir automaticamente as tarifas de frete atuais, sem que o desenvolvedor do site precise inserir a tabela de tarifas da transportadora em um banco de dados web. Embora "API web" tenha sido historicamente quase sinônimo de web service, em 2008 observava-se uma tendência (a chamada Web 2.0) de abandono dos serviços web baseados no SOAP (Simple Object Access Protocol) e da arquitetura orientada a serviços (SOA) em favor de recursos web mais diretos, no estilo de transferência de estado representacional (REST), e da arquitetura orientada a recursos (ROA). Parte dessa tendência está relacionada ao movimento da Web semântica em direção ao Resource Description Framework (RDF), um conceito que promove tecnologias de engenharia de ontologias baseadas na web. As APIs web permitem combinar várias APIs em novas aplicações, conhecidas como mashups.
No campo das redes sociais, as APIs web permitiram que comunidades on-line compartilhassem conteúdo e dados entre comunidades e aplicações. Dessa forma, o conteúdo criado em um lugar pode ser publicado e atualizado dinamicamente em vários locais da web. Por exemplo, a API do X (antigo Twitter) oferece endpoints para pesquisar publicações e para obter os tópicos em alta de uma localização geográfica.
Projeto
O projeto de uma API tem impacto significativo sobre o seu uso. O princípio da ocultação de informação descreve o papel das interfaces de programação como facilitadoras da programação modular, ao ocultar os detalhes de implementação dos módulos, de modo que os usuários dos módulos não precisem compreender as complexidades internas deles. Assim, o projeto de uma API procura fornecer apenas as ferramentas que um usuário esperaria. O projeto de interfaces de programação representa uma parte importante da arquitetura de software, a organização de um software complexo.
Políticas de lançamento
As APIs são uma das formas mais comuns de integração entre empresas de tecnologia. As empresas que fornecem e usam APIs são consideradas membros de um ecossistema de negócios.
As principais políticas para o lançamento de uma API são:
Privada: a API é apenas para uso interno da empresa.
Parceira: apenas parceiros comerciais específicos podem usar a API. Por exemplo, empresas de transporte por aplicativo, como a Uber e a Lyft, permitem que desenvolvedores terceiros aprovados façam pedidos de corridas diretamente de dentro de seus aplicativos. Isso permite às empresas exercer controle de qualidade, selecionando quais aplicativos têm acesso à API.
Pública: a API está disponível para uso do público. Por exemplo, a Microsoft torna pública a API do Windows, e a Apple disponibiliza sua API Cocoa, para que se possa escrever software para suas plataformas. Nem todas as APIs públicas são acessíveis a qualquer pessoa. Por exemplo, empresas de infraestrutura de internet como a Cloudflare oferecem APIs que dão aos clientes acesso a informações e controles de seus serviços, como proteção contra ataques DDoS, análise de tráfego e desempenho da rede. O acesso a essas APIs é concedido por meio de "tokens de API".
Implicações das APIs públicas
Um fator importante quando uma API se torna pública é a sua "estabilidade de interface". Mudanças na API — por exemplo, a remoção de elementos — podem quebrar a compatibilidade com os clientes que dependem dela.
Quando partes de uma API apresentada publicamente estão sujeitas a mudanças e, portanto, não são estáveis, essas partes devem ser documentadas explicitamente como "instáveis". Por exemplo, na biblioteca Google Guava, as partes consideradas instáveis, que podem mudar em breve, são marcadas com a anotação Java@Beta.
Uma API pública pode, às vezes, declarar partes de si mesma como obsoletas (deprecated). Isso geralmente significa que essa parte da API deve ser considerada candidata a remoção, por ter sido substituída por outra. Essas declarações permitem que os desenvolvedores deixem de usar partes da API que serão removidas ou deixarão de ser suportadas no futuro.
O código cliente pode conter usos inovadores ou oportunistas não previstos pelos projetistas da API. Em outras palavras, em uma biblioteca com uma base significativa de usuários, quando um elemento passa a fazer parte da API pública, ele pode ser usado de diversas maneiras.
Em 19 de fevereiro de 2020, a Akamai publicou seu relatório State of the Internet, que mostrava a tendência crescente de criminosos cibernéticos atacarem plataformas de APIs públicas de empresas de serviços financeiros em todo o mundo. De dezembro de 2017 a novembro de 2019, a Akamai observou 85,42 bilhões de ataques de abuso de credenciais. Quase 20% deles, ou 16,55 bilhões, foram dirigidos a nomes de host identificados como endpoints de API. Desses, 473,5 milhões tiveram como alvo organizações do setor de serviços financeiros.
Documentação de API
A documentação de uma API descreve quais serviços ela oferece e como usá-los, com o objetivo de cobrir tudo o que um cliente precisaria saber para fins práticos.
A documentação é crucial para o desenvolvimento e a manutenção de aplicações que usam a API. A documentação de APIs é tradicionalmente encontrada em arquivos de documentação, mas também pode ser encontrada em mídias sociais, como blogs, fóruns e sites de perguntas e respostas.
Os arquivos de documentação tradicionais costumam ser apresentados por meio de um sistema de documentação, como o Javadoc ou o Pydoc, que tem aparência e estrutura consistentes. No entanto, os tipos de conteúdo incluídos na documentação variam de uma API para outra.
Para maior clareza, a documentação de uma API pode incluir uma descrição das classes e dos métodos da API, bem como cenários típicos de uso, trechos de código, justificativas de projeto, discussões sobre desempenho e contratos, mas os detalhes de implementação dos próprios serviços da API costumam ser omitidos. Ela pode assumir várias formas, incluindo documentos instrucionais, tutoriais e obras de referência, e incluir diversos tipos de informação, como guias e descrições de funcionalidades.
As restrições e as limitações sobre como a API pode ser usada também são abordadas pela documentação. Por exemplo, a documentação de uma função de API pode indicar que seus parâmetros não podem ser nulos ou que a própria função não é segura para threads. Como a documentação de APIs tende a ser extensa, é um desafio para os redatores mantê-la atualizada e para os usuários lê-la com atenção, o que pode resultar em defeitos de software.
A documentação de APIs pode ser enriquecida com metadados, como as anotações Java. Esses metadados podem ser usados pelo compilador, por ferramentas e pelo ambiente de tempo de execução para implementar comportamentos ou tratamentos personalizados.
É possível gerar documentação de APIs de forma orientada a dados. Observando muitos programas que usam determinada API, é possível inferir os usos típicos, bem como os contratos e as diretivas exigidos. Em seguida, podem-se usar modelos para gerar linguagem natural a partir dos dados minerados.
Disputa sobre a proteção de APIs por direitos autorais
Em 2010, a Oracle Corporation processou o Google por ter distribuído uma nova implementação de Java incorporada ao sistema operacional Android. O Google não havia obtido permissão para reproduzir a API Java, embora essa permissão tivesse sido concedida ao projeto semelhante OpenJDK. No caso Oracle v. Google, o juiz William Alsup decidiu que os elementos da API Java replicados pelo Google não eram passíveis de proteção por direito autoral nos Estados Unidos e que uma vitória da Oracle teria ampliado consideravelmente a proteção dos direitos autorais a um "conjunto funcional de símbolos", permitindo a proteção de comandos simples de software:
Aceitar a pretensão da Oracle seria permitir que qualquer pessoa protegesse por direito autoral uma versão de código destinada a executar um sistema de comandos e, assim, impedisse todos os demais de escrever suas próprias versões diferentes para executar todos ou parte dos mesmos comandos.
Em 2016, após um julgamento de duas semanas, um júri concluiu que a reimplementação da API Java pelo Google constituía fair use, mas a Oracle anunciou que recorreria da decisão. A Oracle venceu o recurso: o Tribunal de Apelação para o Circuito Federal decidiu que o uso das APIs pelo Google não se qualificava como fair use. Em 2019, o Google recorreu à Suprema Corte dos Estados Unidos contra as decisões sobre a proteção por direitos autorais e sobre o fair use, e a Suprema Corte aceitou examinar o caso em novembro de 2019. Devido à pandemia de COVID-19, as sustentações orais, inicialmente marcadas para março de 2020, foram adiadas para outubro de 2020.
A Suprema Corte decidiu o caso a favor do Google em 5 de abril de 2021.
Exemplos
ASPI (Advanced SCSI Programming Interface), para interface com dispositivos SCSI
OpenMP, API que dá suporte à programação multiprocessada com memória compartilhada em C, C++ e Fortran em diversas arquiteturas, incluindo plataformas Unix e Microsoft Windows
↑Perron, Brian E.; Luan, Hui; Qi, Zia; Victor, Bryan G.; Goyal, Kavin (2024). «Demystifying Application Programming Interfaces (APIs): Unlocking the Power of Large Language Models and Other Web-based AI Services in Social Work Research». arXiv:2410.20211
123Berg, John L.; Graham, Marc; Whitney, Kevin, eds. (abril de 1981). Database Architectures: A Feasibility Workshop Report(PDF). Col: NBS Special Publication (em inglês). Washington, DC: U.S. Department of Commerce, National Bureau of Standards. pp.45–46. 500-76. Consultado em 27 de outubro de 2026
12Cotton, Ira W.; Greatorex Jr., Frank S. (dezembro de 1968). «Data structures and techniques for remote computer graphics». AFIPS '68 (Fall, part I): Proceedings of the December 9–11, 1968, Fall Joint Computer Conference, part I. Col: AFIPS Conference Proceedings (em inglês). 33. San Francisco: Association for Computing Machinery. pp.533–544. doi:10.1145/1476589.1476661
↑«application program interface». Oxford English Dictionary (em inglês) on-line ed. [S.l.]: Oxford University Press Acesso mediante assinatura.
↑Date, C. J.; Codd, E. F. (1975). «The relational and network approaches: Comparison of the application programming interfaces». In: Rustin, Randall. Proceedings of 1974 ACM-SIGMOD Workshop on Data Description, Access and Control (em inglês). 2. Ann Arbor, Michigan: Association for Computing Machinery. pp.83–113. doi:10.1145/800297.811532
↑Dotsika, Fefie (agosto de 2010). «Semantic APIs: Scaling up towards the Semantic Web». International Journal of Information Management (em inglês). 30 (4): 335–342. doi:10.1016/j.ijinfomgt.2009.12.003
↑Odersky, Martin; Spoon, Lex; Venners, Bill (2008). «Combining Scala and Java». Programming in Scala (em inglês) 1 ed. [S.l.]: Artima. Consultado em 27 de outubro de 2026
↑de Figueiredo, Luiz Henrique; Ierusalimschy, Roberto; Celes Filho, Waldemar (1994). «The design and implementation of a language for extending applications». Proceedings of XXI Brazilian Seminar on Software and Hardware (SEMISH 1994) (em inglês). [S.l.: s.n.] pp.273–283. Consultado em 27 de outubro de 2026
↑Winters, Titus; Manshreck, Tom; Wright, Hyrum (2020). «What Is Software Engineering?». Software Engineering at Google: Lessons Learned from Programming Over Time (em inglês). Sebastopol, Califórnia: O'Reilly Media. ISBN978-1-4920-8279-8. Consultado em 27 de outubro de 2026
↑Mastrangelo, Luis; Ponzanelli, Luca; Mocci, Andrea; Lanza, Michele; Hauswirth, Matthias; Nystrom, Nathaniel (23 de outubro de 2015). «Use at your own risk: the Java unsafe API in the wild». Proceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2015) (em inglês). Nova Iorque: Association for Computing Machinery. pp.695–710. doi:10.1145/2814270.2814313
↑Harrand, Nicolas; Benelallam, Amine; Soto-Valero, César; Bettega, François; Barais, Olivier; Baudry, Benoit (2022). «API beauty is in the eye of the clients: 2.2 million Maven dependencies reveal the spectrum of client–API usages». Journal of Systems and Software (em inglês). 184. arXiv:1908.09757. doi:10.1016/j.jss.2021.111134. 111134
↑Peterson, Pearu (2009). «F2PY: a tool for connecting Fortran and Python programs». International Journal of Computational Science and Engineering (em inglês). 4 (4): 296–305. doi:10.1504/IJCSE.2009.029165
↑Fowler, Martin (26 de junho de 2005). «Inversion Of Control». martinfowler.com (em inglês). Consultado em 27 de outubro de 2026
↑Lewine, Donald A. (1991). POSIX Programmer's Guide: Writing Portable UNIX Programs with the POSIX.1 Standard (em inglês). Sebastopol, Califórnia: O'Reilly & Associates. p.1. ISBN978-0-937175-73-6
↑West, Joel; Dedrick, Jason (junho de 2001). «Open source standardization: the rise of Linux in the network era». Knowledge, Technology & Policy (em inglês). 14 (2): 88–112. doi:10.1007/PL00022278
↑Spolsky, Joel (13 de junho de 2004). «How Microsoft Lost the API War». Joel on Software (em inglês). Consultado em 27 de outubro de 2026
↑Gates, Bill; Manzi, Jim; Esber, Ed (2 de novembro de 1987). «The great software debate». Computerworld (em inglês). 21 (44): SR7 Entrevista conduzida por Paul Gillin.
↑Bierhoff, Kevin (23 de abril de 2009). API Protocol Compliance in Object-Oriented Software(PDF) (em inglês). [S.l.]: Carnegie Mellon University, Institute for Software Research. CMU-ISR-09-108. Consultado em 27 de outubro de 2026 Tese de doutorado.
12Wilson, M. Jeff (10 de novembro de 2000). «Get smart with proxies and RMI». JavaWorld (em inglês). InfoWorld. Consultado em 27 de outubro de 2026
↑«Search Posts». X Developer Platform (em inglês). Consultado em 27 de outubro de 2026
↑«Trends by WOEID». X Developer Platform (em inglês). Consultado em 27 de outubro de 2026
↑Garlan, David; Shaw, Mary (janeiro de 1994). An Introduction to Software Architecture(PDF). Col: Technical Report (em inglês). [S.l.]: Carnegie Mellon University. CMU-CS-94-166. Consultado em 27 de outubro de 2026
↑Microsoft (28 de abril de 2021). «API Index – Win32 apps». Microsoft Learn (em inglês). Consultado em 27 de outubro de 2026
↑Apple (18 de setembro de 2013). «What Is Cocoa?». Cocoa Fundamentals Guide (em inglês). Apple Developer Documentation Archive. Consultado em 27 de outubro de 2026
↑Cloudflare. «API Reference». Cloudflare API (em inglês). Consultado em 27 de outubro de 2026
↑Cloudflare (20 de abril de 2026). «Get started». Cloudflare Fundamentals docs (em inglês). Consultado em 27 de outubro de 2026
12Shi, Lin; Zhong, Hao; Xie, Tao; Li, Mingshu (2011). «An Empirical Study on Evolution of API Documentation». In: Giannakopoulou, D.; Orejas, F. Fundamental Approaches to Software Engineering (FASE 2011). Col: Lecture Notes in Computer Science (em inglês). 6603. [S.l.]: Springer. pp.416–431. ISBN978-3-642-19810-6. doi:10.1007/978-3-642-19811-3_29
↑Mendez, Diego; Baudry, Benoit; Monperrus, Martin (2013). «Empirical evidence of large-scale diversity in API usage of object-oriented software». 2013 IEEE 13th International Working Conference on Source Code Analysis and Manipulation (SCAM) (em inglês). [S.l.]: IEEE. pp.43–52. arXiv:1307.4062. doi:10.1109/SCAM.2013.6648183
↑Dekel, Uri; Herbsleb, James D. (2009). «Improving API documentation usability with knowledge pushing». 2009 IEEE 31st International Conference on Software Engineering (ICSE 2009) (em inglês). [S.l.]: IEEE. pp.320–330. doi:10.1109/ICSE.2009.5070532
12Bruch, Marcel; Mezini, Mira; Monperrus, Martin (2010). «Mining subclassing directives to improve framework reuse». 2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010) (em inglês). [S.l.]: IEEE. pp.141–150. doi:10.1109/MSR.2010.5463347
↑Monperrus, Martin; Eichberg, Michael; Tekes, Elif; Mezini, Mira (2012). «What should developers be aware of? An empirical study on the directives of API documentation». Empirical Software Engineering (em inglês). 17 (6): 703–737. arXiv:1205.6363. doi:10.1007/s10664-011-9186-4
↑Oracle. «Lesson: Annotations». The Java Tutorials (em inglês). Consultado em 27 de outubro de 2026
↑Suprema Corte dos Estados Unidos (15 de novembro de 2019). «Order List»(PDF) (em inglês). Consultado em 27 de outubro de 2026 Ver "Certiorari Granted: 18-956 Google LLC v. Oracle America, Inc."
↑Suprema Corte dos Estados Unidos (16 de março de 2020). «Press Releases – pr_03-16-20» (em inglês). Consultado em 27 de outubro de 2026
↑Suprema Corte dos Estados Unidos. «Docket for 18-956» (em inglês). Consultado em 27 de outubro de 2026
Leitura adicional
Bucher, Taina (16 de novembro de 2013). «Objects of Intense Feeling: The Case of the Twitter API». Computational Culture (em inglês) (3). ISSN2047-2390 Argumenta que as APIs "estão longe de ser ferramentas neutras" e as trata como um elemento básico da web social, que afeta a cultura.
Ondrejka, Cory (28 de fevereiro de 2014). «Maury, Innovation, and Change» (em inglês). Consultado em 27 de outubro de 2026 Relaciona a proposta feita por Maury em 1853, na Conferência Marítima de Bruxelas, de um formato padronizado para dados meteorológicos à ideia de uma API pública.
Suprema Corte dos Estados Unidos (5 de abril de 2021). «Google LLC v. Oracle America, Inc., No. 18–956»(PDF) (em inglês). Consultado em 27 de outubro de 2026 A seção What is an API? (pp. 3–8) explica o conceito: "por meio de uma API, um programador pode recorrer a uma vasta biblioteca de código pré-escrito para executar tarefas complexas".
Ligações externas
Forrester (20 de maio de 2021). «IT Industry Breathes A Sigh Of Relief In API Case». What It Means (podcast), episódio 218 (em inglês). Consultado em 27 de outubro de 2026 Com David Mooter e Sandy Carielli.
