BT

Início Notícias Os custos para versionamento de uma API

Os custos para versionamento de uma API

Favoritos

O versionamento de contrato e o versionamento de API/Serviços sempre foram motivos de preocupação em sistemas baseados em SOA. Seja devido ao impacto que existe sobre a modularidade, ou a governança cliente-serviço. Neste cenário, versionamento ainda é uma espécie de arte mais do que uma ciência. Há muitos exemplos de grupos publicando o benefício de suas experiências (por exemplo, o REST é extremamente popular). Entretanto, Jean-Jacques Dubray escreveu um artigo recentemente que tenta injetar algum objetivo científico nesse domínio de problema.

Pediram-me recentemente para criar uma estimativa dos custos de versionamento de APIs (ou WebServices). Gostaria de compartilhar essa estimativa porque sinto que muitas pessoas continuam não entendendo o custo e as implicações ao se versionar uma API/Serviço.

De acordo com Jean-Jacques Dubray, durante o trabalho, foi descoberto que o custo de construção de APIs dependia da abordagem a ser utilizada posteriormente para o versionamento dessas APIs.

A parte mais importante a entender é, mesmo que o custo para os consumidores pareça pequeno para você, não se trata de apenas um custo puro, isso é risco, interrupção em planos de projetos, orçamentos indisponíveis… com mudanças que não tem valor de negócio imediato para um cliente real que não espera nenhuma mudança na API.

O artigo então passa a classificar três diferentes abordagens para o controle de versão de uma API (veja o artigo completo para se aprofundar em cada assunto, incluindo como o autor define uma maneira para mensurar custos):

  • O Nó - "Todos os consumidores estão vinculados a uma única versão da API, quando a API muda, todos consumidores tem que mudar, basicamente criando um massivo efeito em cascata em todo o conjunto de consumidores / ecossistemas."

  • Ponto a Ponto - "Cada versão do serviço é deixada em execução e em produção e os consumidores são obrigados a mudar por conta própria, quando eles desejarem. O custo de manutenção aumenta conforme o número de versões em produção aumenta."

  • Versionamento Compatível - "Todos clientes conversam com a mesma versão de API/Serviço compatível."

Dadas essas definições e os custos associados computados utilizando as equações que Jean-Jacques Dubray descreve, é possível traçar os custos relativos como mostrado abaixo (o eixo y é o custo, o eixo x é o número da versão):

Sobre os custos relativos, o autor escreveu que:

[...] uma única versão forçando cada consumidor a migrar quando a API muda é o custo mais caro para o ecossistema. A multiplicidade de versões que precisam ser mantidas é melhor, mas ainda muito caro quando você tenta manter atualizada cada versão, ou alternativamente, funcionando em versões mais antigas. A estratégia de versão compatível parece oferecer a melhor eficiência.

Então o que os outros acham dessa abordagem? É esta a maneira que Jean-Jacques Dubray e sua equipe calculam o custo de versionar APIs aplicados além dos ambientes no qual eles foram desenvolvidos? A explicação relativa dos custos faz sentido dado sua própria experiência? Existem outras categorias que Jean-Jacques Dubray e sua equipe não cobriram?

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Comentários da comunidade

  • Versões compatíveis, ou poucas versões

    by Maluko .. /

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    A meu ver, ao mesmo tempo que é preciso lançar novas features, também é necessário dar um tempo para a migração de versão. Manter compatibilidade com todas as versões antigas até hoje não me pareceu compensar o custo.

  • Interessante.

    by Gabriel RB /

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Pra mim q não tenho experiência com desenvolvimento de APIs, foi muito construtivo o artigo!
    Não sei qual abordagem se adaptaria melhor a minha realidade. Mas gostei da abordagem de versões diferentes rodando em produção.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.