Interfaces de Programação
API (Application Programming Interface, ou Interface de Programação de Aplicações) é um termo muito comum no dia a dia de um profissional de análise de sistemas.
Nos tempos atuais raramente se vê sistemas que trabalham “sozinhos” como víamos muito na época na computação centralizada (Mainframe), mas até mesmo nos OS/390 por aí existe muito programa Assembly, Cobol etc. que são repositórios de funções que acabam fazendo o papel de API’s.
Mesmo sendo um conceito muito comum no dia a dia do analista de sistemas, vez ou outra é empregado de maneira não muito adequada; em alguns casos uns restringem muito o conceito de API, em outros, abrangem demais.
Em função de um desalinhamento sobre o conceito e para compor a base de posts conceituais deste blog, resolvi escrever este breve post.
O que é API e o que não é API
Uma API tem por objetivo principal disponibilizar recursos de uma aplicação para serem usados por outra aplicação, abstraindo os detalhes da implementação e muitas vezes restringindo o acesso a estes recursos com regras específicas para tal.
Caso trate-se de algo que encapsule parte da implementação de uma aplicação e disponibilize a implementação para outra aplicação utilizar, é uma API.
Se estamos falando de abstrações/código encapsulado dentro de uma mesma aplicação e com interfaces específicas para uso, não é API, pode ser biblioteca, framework ou algo do tipo.
Basicamente, se trata-se de recurso “oferecido” dentro da fronteira da aplicação então não é API, se é recurso oferecido fora da fronteira da aplicação e é possível outra aplicação acessá-lo via programação, então é API.
Reuso, Centralização e Integração
Uma API tem três principais objetivos: 1) possibilitar reuso de lógicas, uma vez que expondo uma função ou método por exemplo, o código do respectivo não precisa ser duplicado no contexto da solução, 2) centralizar lógica (premissa para coesão) viabilizando num ponto único de uma solução o acesso a tal lógica, 3) viabilizar integração com outras aplicações quando a integração é mais “baixo nível”, demandando acesso a recursos internos da aplicação.
Tipos de API
Conceitualmente uma API é uma coisa só, como vimos. Mas em termos de desenvolvimento de software uma API pode ser construída de várias formas. As mais utilizadas são:
DLL – Dynamic-link library: são executáveis resultantes de classes ou conjuntos de classes compiladas em ambientes como .Net e Delphi, por exemplo. Incorporado numa DLL, conforme as regras de visibilidade aplicadas, são expostos vários métodos/funções que podem ser utilizadas por terceiros.
Plugins: atualmente é um dos modos mais utilizados em função da maturidade da web 2.0. Em aplicações web mais simples, atualmente, eu me arrisco a afirmar que 50 por cento do código é da própria aplicação, o restante é consumido de plugins diversos. Quando falamos de um blog WordPress por exemplo (como é este que uso) a maioria dos recursos são resultado de consumo de plugins (exemplos são uso de captcha, envio de e-mail e feed, anti-spam, otimizador de SEO, analisador de estatísticas etc.).
Frameworks: quando temos um framework exclusivo de um sistema não trata-se de API, pois não há exposição de recursos nem integração com outros sistemas. Quando há, geralmente trata-se de um framework que prove um conjunto de API’s para consumo. No mundo web grandes exemplos de frameworks que “fazem mágica” para seus usuários são JQuery e Bootstrap.
WebAPI: basicamente são API’s utilizadas em soluções web (algo dentro da www). WebAPI’s podem ser client-side ou server-side (executadas no front ou no back-end de uma aplicação web). Eu não gosto desta definição, pois a web é um pedaço pequeno da internet, que tem muito mais que a parte gráfica como vemos; talvez Internet API seria melhor…
… mas é WebAPI. Neste contexto falamos de Serviços Web (sejam WebServices SOAP, WCF com SOAP, Rest, JSON, TCP etc., WebAPI de .Net e semelhantes). Quando fala-se de SOA – Arquitetura Orientada a Serviços – na prática é um conjunto de WebAPI’s organizadas de forma específica e disponíveis para um eco-sistema utilizá-las.
Não existem apenas os tipos citados, existem vários outros mas penso que os citados são os mais utilizados atualmente. É isso, eu adoro API’s pois lidar com integração em nível de programação é um trabalho super interessante.
Dica de uso
Existem boas práticas quando lidamos com API’s, mas uma específica talvez seja a principal: cuidado ao publicar uma API, pois se parte de sua lógica estiver exposta do jeito errado, consertar isso após a publicação será desastroso. Neste post – WebService – Cuidado ao publicar um WebMethod – falo um pouco sobre isso, no contexto de um WebService.
Abraços!