banner ads

Hypermedia APIs – Parte I

Estamos cansados de saber dos problemas de se desenvolver software de forma rígida, dificultando atualizações de negócio pontuais e de impacto considerável.

Inúmeras técnicas e práticas, nos auxiliam a atingir exatamente isso, um código saudável e apto a evolução.

Sabemos também que muitas vezes uma determinada regra de negócio é por algum motivo adicionada ao código de uma maneira despretensiosa e sem muito planejamento, e você tem 95% de chance dessa regra mudar algum dia, e o que é apenas

um deslize pode se transformar em uma avalanche.

Uma API (Application programming interface) pode nos ajudar bastante a resolver questões que lidam com extensabilidade, encapsulamento e separação do conhecimento entre partes do software, também é sábio dizer que não é sempre

(até porque no mundo da TI não existe sempre) que uma regra de negócio vital ao seu sistema deva ficar “guardada” dentro de uma.

Alguns problemas que muitas vezes são resolvidos de forma descentralizada e que a cada necessidade surge uma nova maneira de fazê-lo, é um exemplo de uma possível necessidade de uma API.
Nessa série de posts, vou tentar explicar o porque APIs especificamente baseadas em Hypermedia podem te ajudar nesses problemas, se você não entende a definição de API sugiro que leia isso antes de continuar a leitura e também uma introdução sobre RESTful Web APIs.

Algumas APIs entituladas RESTFul não seguem totalmente as definições de REST criadas por Roy T. Fielding, portanto o nome Hypermedia API ficou e está cada vez mais popular, o desenvolvedor que entende REST e sua aplicação prática sabe que se sua API é baseada puramente em Hypermedia é assim que ela deve ser tratada.

Hypermedia nos fornece uma resposta que representa o estado da aplicação. Dessa forma o crescimento e a opção pelo uso de hypermedia é mais uma forma de se estender uma aplicação. Mantendo a linha da extensibilidade, não podemos esquecer que nem sempre o client está(ou estará) utilizando a mesma tecnologia que o server, e uma maneira segura e efetiva dessa “comunicação” ocorrer é através de mensagens, mas imagina como seria pobre essa comunicação se ela fosse estabelecida através de plain text?

Mensagens que formam um objeto e sua representação são essenciais para esse tipo de comunicação, além de serem muito mais robustas e de simples implementação.

Quando uma aplicação é desenvolvida de maneira que diversas APIs serão utilizadas para se resolver uma série de problemas e pelos outros motivos já citados, temos que pensar sempre como e quando chamar determinada função. Óbvio, pensando em algo stateless e totalmente fora de contexto esse tipo de resposta é inevitável, portanto na maioria das vezes cabe ao client decidir quais decisões tomar e qual o próximo passo a seguir, baseando-se na resposta de uma função, uma vital diferença de se trabalhar com hypermedia é que esse tipo de “troca” ocorre através de parâmetros enviados a uma função que te responde o atual estado da aplicação, e quais os prováveis passos seguintes, reduzindo consideravelmente a necessidade de desenvolvimento de regras e controle de fluxos no client. Basicamente, a “media” para os próximos passos são servidas no corpo da mensagem e indicam as transições possíveis.

Exemplo simplificado uma chamada de uma mensagem simples:


HTTP GET > http://api.bluesoft.com.br/produtos/
... {

“key” : “f6a29751-e2cc-4ebc-a881-b6f5b90eec6b”,

“nome” : “Acelerato”,

“description” : “O sistema ideal para integrar o seu atendimento ao cliente e o desenvolvimento de seu projeto.”

},

{

“key” : “d502015b-f678-48e3-9b6e-ebfa766152c9”,

“nome” : “Bluesoft ERP”,

“description” : “Sistema de gestão para supermercados”

}

Não vamos nos aprofundar em outros fundamentos de State transitions servidos como url (será explicado em outro post), a idéia é ilustrar uma chamada simples e um retorno simples.

Com esse retorno eu tenho vaŕias opções de fluxo, e isso fica a critério de quem está consumindo, para obter mais detalhe sobre o Acelerato, por exemplo, eu faria algo desse tipo:

HTTP GET > http://api.bluesoft.com.br/produtos/Acelerato

ou pelo key, como ele foi me enviado significa que posso utilizá-lo como parametro nas minhas operações:


HTTP GET > http://api.bluesoft.com.br/produtos/f6a29751-e2cc-4ebc-a881-b6f5b90eec6
{

“url” : “http://www.acelerato.com/”,

“planos” : “[{

‘tipo’: ‘básico’,

‘funcionalidades’: ‘[Helpdesk, Clientes ilimitados, 1 GB por usuário]’

},

{

‘tipo’: ‘profissional’,

‘funcionalidades’:'[Helpdesk, Spaces, 2 GB por usuário]’

}]”

}

Mesmo com essa extensão as coisas acontecem sem muita consistência, a resposta não conseguiu demonstrar o seu estado e pra onde você pode ir, e se tivemos que fazer duas chamadas no mínimo para se obter o detalhe de um produto?
Pensando em larga escala isso pode gerar problemas maiores.

Nessa série de posts, iremos mostrar como hypermedia pode nos ajudar a tornar as coisas mais contextualizadas, representando um domínio e suas operações, nos levando a transições de forma segura, nos ajudando a diminuir a quantidade de código desenvolvido e aumentando o seu reuso, maximizando a velocidade de implementação de novas features.

 

Não deixe de nos acompanhar, abraços!

Vinicius Mesquita

 

>>> Hypermedia APIs – Parte II

 

Related Articles:

—————————————-­—————————————-­—-

Este Post é um oferecimento de Acelerato – Gestão de Projetos ágeis e Help Desk

Não perca tempo, acesse acelerato.com, cadastre-se gratuitamente e descubra como podemos ajudá-lo.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

1 Comments

Leave a comment