"As APIs públicas são para sempre: apenas uma chance de acertar"?

Em um livro do sistema operacional, acabei de ler: "APIs públicas são para sempre: apenas uma chance de acertar". É verdade? É aplicável apenas em APIs de sistemas operacionais ou em outras APIs também? Por exemplo, isso será verdade para as APIs de aplicativos Android, como Tasker, Locale e Pushover?

Geralmente é verdade para qualquer API pública, sim. Depois que você expõe uma API ao público e as pessoas começam a criar aplicativos que dependem dessa API, torna-se extremamente difícil alterar a API, pois isso interromperá todos esses aplicativos. Isso tende a ser um problema técnico difícil e um problema político difícil.

Obviamente, é possível alterar uma API pública. Por exemplo, acontece que os projetos privam uma API em uma versão, introduzem uma nova API e removem a API antiga em alguma versão futura. Mas isso pressupõe que todos os aplicativos (importantes) que usam a API antiga serão reescritos para usar a nova API antes que a API antiga seja removida. Isso geralmente leva vários anos. E isso significa que o proprietário da API pública está impondo um custo a todos os outros projetos que consomem a API. Como geralmente há muito mais consumidores de uma API, esses consumidores tendem a ser um lobby político relativamente poderoso.

O autor da citação é Joshua Bloch, a declaração é de seu artigo da API de adesivos para carros :

APIs públicas, como diamantes, são para sempre. Você tem uma chance de acertar, então dê o seu melhor.

Para mais detalhes sobre isso, o autor encaminha os leitores para a apresentação da sessão da conferência, "Como criar uma boa API e por que ela é importante" . Slide Por que o design da API é importante para você, afirma claramente que isso é relevante para qualquer atividade de programação (sistemas operacionais ou não, não importa para o autor):

• Se você programa, você é um designer de API

  • Um bom código é modular - cada módulo possui uma API

• Módulos úteis tendem a ser reutilizados

  • Depois que o módulo tiver usuários, não será possível alterar a API à vontade
  • Bons módulos reutilizáveis ​​são ativos corporativos

• Pensar em termos de APIs melhora a qualidade do código

A Conclusão do slide também enfatiza isso como uma abordagem geral:

• O design da API é uma arte nobre e gratificante

  • Melhora o número de programadores, usuários finais, empresas ...

As APIs sempre mudam; caso contrário, qual seria o objetivo da atualização do sistema? Mudando apenas os internos?

Cada versão do sistema traz novas APIs, as APIs antigas se tornam obsoletas e as APIs obsoletas desaparecem.

A alteração da API só precisa ser muito cuidadosa tanto tecnicamente quanto em termos de comunicação.

Minha opinião seria que, uma vez lançada, essa 'versão' da API é eterna, mas você pode descontinuá-la liberando uma API '2.0' (há vários exemplos em que isso está acontecendo - atualmente, eu posso pensar no Strava que lançou uma versão 2.0 de uma API para desenvolvimento contra consumir seus serviços).

O problema está no suporte à API original ad infinitum ... Acho que depende do uso da API antiga e do valor que esses consumidores da API têm para você.

Voltando aos "velhos tempos", como o Windows 3.xe 9x etc., uma vez lançados, essas APIs do sistema operacional estavam prontas e definidas. Agora, as atualizações do sistema operacional são atualizadas o tempo todo, para que novas APIs possam ser lançadas, mas acho que, desde que você esteja executando um tipo específico de sistema operacional (versão principal), essas APIs seriam adicionadas e nunca removidas ... seja o caso do 'próximo' grande lançamento.

Hmm, talvez eu tenha me desviado da intenção original da pergunta.

Depende de qual tipo de API é (e eu estou assumindo alterações quebradas, caso contrário, a declaração obviamente não é verdadeira).

Se o chamador puder escolher a versão que está usando (por exemplo, com bibliotecas / estruturas que acompanham o aplicativo de chamada), a alteração da API não é um problema enorme - mas ainda prejudica a reputação do software. As pessoas gostam de atualizar sem problemas.

Por outro lado, quando as pessoas não podem continuar usando a versão antiga da API (como em um serviço online ou coisas como um navegador ou SO em que a execução de versões antigas é muito indesejável), alterar as APIs de maneira incompatível é muito ruim. de fato, uma vez que interromperá todo o software que o usa e não é atualizado também. Isso impõe um custo de manutenção aos desenvolvedores, e eles o odeiam por isso. E o software que não é mantido e quebras também refletirá mal em você.

Por outro lado, há pelo menos um provedor de API que constantemente introduz alterações na API e é ridiculamente bem-sucedido de qualquer maneira: o Facebook. Mas eles gerenciam as alterações com muito cuidado: há uma política publicada , as alterações mais recentes são anunciadas e explicadas com pelo menos 90 dias de antecedência, e os desenvolvedores podem optar por ativá-las no início desse prazo.

Se você tiver a previsão de incluir um número de versão na própria API. Na chamada de conexão / inicialização ou, em algum lugar próximo ao início da lista de parâmetros em cada chamada, sua API pode evoluir e sofrer alterações ao longo do tempo sem interromper os clientes existentes.

Embora tudo o que fazemos seja torná-los melhores de uma só vez, mas desde a mudança e o aprimoramento do tempo, às vezes precisamos atualizar as informações, como muitos fornecedores gigantes estão fazendo (como o livro de rosto várias atualizações, o twitter uma das principais). voltando-se para oAuth e vários dos principais, mas, no máximo, tudo vem com melhorias, portanto não há mudanças frequentes.E sim, por favor, não pare de apoiar um antigo, dói !! :)

Sempre que você libera qualquer tipo de protocolo de comunicação, que obviamente incluiria uma API, você tem uma chance de acertar no sentido de que o protocolo / interface deve ser compatível com versões anteriores e extensível.

Isso permite que você adicione novas funcionalidades e libere novas versões sem precisar se preocupar em quebrar as pessoas que estão usando versões mais antigas. Nunca no mundo do software, você terá uma situação em que poderá sofrer uma transição difícil em um determinado momento, e todo mundo descarta a versão antiga e começa a usar a nova versão.