2.3.1 Introdução
API136 consiste num conjunto de padrões e procedimentos que os programas de
software podem seguir para comunicar entre si. Serve de interface entre vários programas de software e facilita a sua interação, de forma semelhante a uma interface de utilizador que facilita a interação entre humanos e computadores.
Ao longo dos anos foram vários os desenvolvimentos registados na evolução das API. Com o aparecimento dos sistemas distribuídos nos anos 70, as API tiveram uma grande evolução. Um dos principais avanços foi o Message Oriented Middleware, respondendo às necessidades especi cas da EAI137, oferecendo ligação entre sistemas
distribuídos utilizando integração API. O exemplo mais notório foi o IBM138
MQSeries139 que introduziu tecnologias de troca de mensagens entre sistemas
distribuídos.
No nal da década de 80 as API tiveram outra grande evolução com o aparecimento da programação orientada a objetos e as aplicações complexas puderam organizar-se como objetos.
Durante a década de 90 os sistemas distribuídos tornaram-se ainda mais populares com o surgimento da www comercial e evolução das tipologias cliente-servidor. Também novas técnicas de programação orientada a objetos emergiram o que facilitou o acesso remoto a instâncias de objetos. Tim Berners-Lee no inicio da década surgiu também com o prototipo do primeiro navegador e com ele a primeira página HTML. Em 1995 surgiu o JavaScript, contribuindo signi cativamente para a evolução das API, nomeadamente no desenvolvimento de aplicações do lado do cliente. Finalmente a história e integração de API teve no nal da década o
136Application Programming Interface. 137Enterprise Application Integration.
138Empresa multinacional americana de tecnologia da informação sediada em Armonk, Nova
York, Estados Unidos, com operações em mais de 170 países.
139Família de software cujos componentes são utilizados para unir outras aplicações de
contributo do SOA140, que é uma abordagem arquitetural que permite a criação
e reutilização de serviços de negócio interoperáveis e partilhados entre aplicações e empresas.
Nesta década os programadores aperceberam-se que o modelo www existente e a sua infraestrutura técnica poderia ser utilizada para melhorar a camada intermédia (middleware) utilizada até este ponto.
Atualmente vivemos os tempos da Web API, que começou por volta de 2005. A integração de API fez com que surgissem plataformas como o Ebay141 ou a
Amazon142 que hoje em dia gozam de enorme popularidade(EBizMBA,2018).
Na implementação de serviços web na tecnologia REST não existem padrões de nidos para a documentação e descrição de um determinado serviço. Por conseguinte existem alguns métodos (ferramentas) utilizados para a descrição de uma API REST, que permitem de forma automática manter a documentação atualizada e sincronizada com o desenvolvimento da API. Posteriormente serão revistas algumas linguagens de especi cação como o RAML, Slate, API blueprint, I/O Docs e o Swagger / OpenAPI.
140Service-Oriented Architecture.
141Empresa de comércio eletrónico fundada nos Estados Unidos, em Setembro de 1995, por
Pierre Omidyar.
142Empresa americana de comércio eletrónico e computação na nuvem sediada em Seattle,
2.3.2 RAML
RAML (RAML Workgroup,2013) é a RESTful API Modeling Language que facilita a gestão de toda API desde a conceção à partilha. É baseada em YAML143 e fornece
toda a informação necessária à descrição de API REST. Incentiva a reutilização, possibilita a descoberta e a partilha de padrões e um dos seus principais objetivos é uni car critérios e incentivar as melhores práticas na descrição de API(Stowe,2015).
2.3.3 Slate
Slate (Lord, 2013) é uma linguagem que permite criar documentação estática e responsiva144 de uma API. Tem como principais características: desenho limpo e
intuitivo, toda a documentação gerada numa única página, utiliza Markdown145,
escrita de código em várias linguagens, realce de sintaxe de código (syntax highlighting146), deslocamento automático de conteúdos, permitidas contribuições
publicas de edição de documentação, suporte para linguagens RTL147, etc.
2.3.4 API blueprint
API blueprint (API Blueprint, 2016) é uma conjunto de ferramentas de desenvolvimento de documentação de todo o ciclo de vida de uma API, disponível ao desenvolvimento individual ou coletivo. A sintaxe é concisa e expressiva. Tem como principais características: colaboração / desenvolvimento de API /
143Formato de serialização (codi cação de dados) de dados legíveis por humanos e inspirado
em linguagens como XML, C, Python, Perl, assim como o formato de correio eletrónico especi cado pela RFC 2822.
144Abordagem ao design da web que torna as páginas da web renderizadas em uma variedade
de dispositivos e tamanhos de janelas ou telas.
145Linguagem simples de marcação originalmente criada por John Gruber e Aaron Swartz.
Markdown converte texto em HTML válido.
146Funcionalidade disponível em alguns editores de texto que apresenta texto - em especial
código fonte - numa formatação especí ca para cada categoria de termos.
governance(Drake and Force, 2005) e entrega, código aberto (Licença MIT148), em
repositório no Github149, construido para permitir melhores desenhos de API através
de abstração, diversas ferramentas que garantem o desenvolvimento / governance e entrega, etc.
2.3.5 I/O Docs
I/O Docs (Mashery, 2011) é um sistema de documentação interativo de web API RESTful. A API é de nida a nível de recursos, métodos e parâmetros através de um schema JSON gerando uma interface cliente em JavaScript. Os pedidos da API podem ser executados através da interface cliente, que são reencaminhados pelo servidor I/O Docs para gerar dados formatados em JSON ou XML. Tags de texto básicas de HTML são habilitadas no shcema JSON.
2.3.6 Swagger / OpenAPI
Swagger / OpenAPI (Open API Initiative, 2016) é um conjunto de ferramentas utilizadas para desenho / documentação / testes / distribuição de uma API. Constitui a mistura de ferramentas livres e comerciais desenvolvidas por engenheiros e gestores. O Swagger / OpenAPI é construido pela SmartBear Software150. Assim
este sistema suporta o desenvolvimento de API nas várias fases do seu ciclo de vida: desenho, construção, documentação, teste, padronização.
148Universidade privada de pesquisa localizada em Cambridge, Massachusetts, Estados Unidos.
Fundada em 1861, em resposta à crescente industrialização dos Estados Unidos, o MIT adotou um modelo europeu de universidade politécnica e salientou a instrução laboratorial em ciência aplicada e engenharia.
149Plataforma de hospedagem de código-fonte com controlo de versão utilizando o Git. 150Empresa privada de tecnologia da informação que fornece ferramentas para monitorização
2.3.7 SERIN
SERIN (Lira et al., 2015) é uma IDL (Interface de nition language) utilizada para de nir modelos abstratos e concetuais que descrevem serviços web RESTful de forma sintática e semântica. O servidor implementa a interface dos serviços RESTful para aceder a recursos que são instâncias da classes especi cadas na interface abstrata. O SERIN permite anotações que determinam as operações (GET, POST, PUT e DELETE) que os serviços RESTful podem desempenhar, bem como especi cam restrições de integridade.
2.3.8 Conclusão
A utilização de linguagens de especi cação de API é vantajosa em termos de poupança de tempo na escrita de código, pois existem ferramentas que permitem gerar uma grande parte de código. Em termos colaborativos também é importante, pois o processo criativo / especi cativo pode envolver todas as partes ligadas à utilização da API. A qualidade da API implementada também pode ser assegurada pois existem mecanismos de validação da API com a especi cação desenvolvida. No caso de uma API REST, como é o caso da implementação prática desta dissertação, é notável e necessária a utilização deste tipo de linguagens, pois não existem mecanismos próprios de especi cação. Em fase nal de implementação da API, também é agilizado o processo de publicação e geração de documentação interativa.