Descontinuar uma API da web: práticas recomendadas?

15

Eventualmente, você precisa depreciar partes de sua API da web pública. No entanto, estou confuso sobre qual seria a melhor maneira de fazer isso. Se você tem uma grande base de aplicativos de terceiros, apenas arrancar versões antigas da API parece ser a maneira errada de fazer isso, já que quase todos os aplicativos falhariam durante a noite. No entanto, você não pode manter a antiga web api disponível para sempre, pois pode estar desatualizada ou há mudanças significativas que impossibilitam o trabalho com ela.

Quais são algumas das práticas recomendadas para suspender as APIs antigas da web?

    
por TheLQ 05.03.2011 / 18:28
fonte

3 respostas

15

Parece que o autor original já informou efetivamente, mas desatou informalmente sua API (qualquer coisa que seja chamada de "API antiga"). No entanto, até que seja anunciado e os usuários sejam notificados de que uma API está obsoleta, ela não será formalmente reprovada.

A API obsoleta é um estágio de código inativo e temporário. São os últimos ritos. Este é o período que permite que os usuários / consumidores reconfigurem seus aplicativos para uma API mais recente e ofereçam uma despedida especial, fazendo as pazes com a API. Algumas APIs podem demorar mais que outras, mas neste momento sabemos que seu tempo não é longo.

A API excluída é um funeral de código. Não há mais nada que possa fazer, mas adequadamente disposto e adequadamente memorializado.

Muitos desenvolvedores de serviços e API optam por funerais de código em vez de realizar os últimos ritos; no entanto, acho que é um pouco arriscado. Se houvesse qualquer tipo de serviço ou promessa de suporte feito quando a API / serviço foi inicialmente adotada ou através de renovação, você pode querer honrar esse compromisso por um período de tempo razoável antes de realizar o funeral.

Para bibliotecas que não são de serviço, acho que uma versão principal, independentemente do período de tempo, é provavelmente um período mais do que aceitável e justo de compatibilidade com versões anteriores garantidas. Além disso, depende da influência e do lobby dos usuários para estender sua vida além desse período. E não fique surpreso se, de tempos em tempos, houver objeções devido a dependências insubstituíveis de terceiros estarem presas no limbo e ligadas a certas versões de certas plataformas.

Para serviços, suspeito que você queira examinar um período de seis meses ou um ano, simplesmente devido à variação de quem e por como um serviço pode ser consumido, e a variação do ciclo de desenvolvimento correspondente de consumir projeto em consumo. projeto - muitos projetos que podem consumir seu serviço ainda podem ter um grande projeto inicial e podem programar um ciclo de lançamento de mais de um ano. A maioria das opiniões de desenvolvedores de fora sugere que aqueles com cronogramas longos são responsáveis por atender seus tempos de ciclo, e esses projetos de ciclo longo devem adotar um ciclo de lançamento mais rápido, e isso pode ser verdade. Mas, no final, a data de exclusão é algo que você precisa negociar com os usuários.

Uma estratégia boa, mas não à prova de balas, para deprecação pode ser ao anular a desaprovação, destacar o prazo para a intenção de excluir, juntamente com uma solicitação de comentário ou objeção em um formato de pesquisa das seções da API em questão. Se você não tiver uma lista de contatos de usuários porque o seu serviço opera com acesso [semi] anônimo, você pode considerar procurar logs para usuários frequentes e ativos e despachar a notificação para o host ou administrador do domínio para encaminhar como achar melhor.

    
por 06.03.2011 / 02:22
fonte
6

A maioria das APIs da Web que eu uso (de empresas como Google, Yahoo! e Microsoft) tem um período de "pôr do sol". Os desenvolvedores são informados dentro de um prazo razoável (digamos, de 3 a 6 meses) dos recursos que serão depreciados para que tenham tempo suficiente para fazer o upgrade antecipadamente.

Você pode adicionar os detalhes dos períodos do pôr do sol nos seus Termos de Serviço ou em outra documentação para que as pessoas saibam como isso funciona. Isso significa que, quando alguém decide usar sua API, saberá com quais agendamentos precisa trabalhar. Por exemplo, você pode informar às pessoas que elas precisarão atualizar seu sistema uma vez por ano e terão 4 meses de antecedência para fazê-lo.

Também é uma boa idéia usar a numeração de versões para dizer que, por exemplo, "a versão 3 será depreciada em breve, portanto, certifique-se de que seu código funcione com a versão 4" etc. Dessa forma, as pessoas saberão que trabalhando com a versão 4, eles estão prontos para o pôr do sol.

    
por 05.03.2011 / 18:49
fonte
0

Além das respostas existentes, você deve fornecer uma substituição imediata ou um plano de migração ao remover algo, para que seus usuários possam atualizar o código.

Tente evitar a remoção da funcionalidade sem fornecer uma alternativa. Isso faria alguns usuários ficarem infelizes.

    
por 13.07.2014 / 11:25
fonte

Tags