Geralmente, deve-se desenvolver uma biblioteca cliente para serviços REST para ajudar a evitar quebras de API?

Temos um projeto em que o código da interface do usuário será desenvolvido pela mesma equipe, mas em uma linguagem diferente (Python / Django) da camada de serviços (REST / Java). O código para cada camada sai em diferentes repositórios de código e pode seguir diferentes ciclos de liberação. Estou tentando criar um processo que impeça / reduza as alterações na camada de serviços da perspectiva da camada da interface do usuário.

Pensei em escrever testes de integração no nível da camada da interface do usuário que executaremos sempre que criarmos a interface do usuário ou a camada de serviços (estamos usando o Jenkins como nossa ferramenta de IC para criar o código que está em dois repositórios Git) e se Se houver falhas, algo na camada de serviços quebrou e a confirmação não foi aceita.

Também seria uma boa idéia (é uma prática recomendada?) Fazer com que o desenvolvedor da camada de serviços crie e mantenha uma biblioteca-cliente para o serviço REST que existe na camada da interface do usuário que eles atualizarão sempre que houver uma alteração de interrupção no API de serviço deles? É concebível que teríamos a vantagem de uma API de tipo estatístico que compõe o código da interface do usuário. Se a API da biblioteca do cliente for alterada, o código da interface do usuário não será compilado (portanto, saberemos mais cedo que houve uma alteração de quebra). Eu também continuaria executando os testes de integração ao criar a interface do usuário ou a camada de serviços para validar ainda mais que a integração entre a interface do usuário e o (s) serviço (s) ainda funcione.

Em geral, para os métodos da API que estão desaparecendo, escolha uma convenção e os 'preteram', especialmente assim que uma API de substituição completa estiver disponível e testada. Deixe a API antiga no lugar (essencialmente), mas marque os metadados da assinatura do método ou insira um evento de log para que o uso possa ser claramente identificado.

O registro na API de serviço é uma coisa, mas alertar os clientes consumidores é outra. Para o REST, acho que não há uma prática sólida e padrão. Os clientes da API do FourSquare podem descobrir métodos obsoletos, mesmo que o método chamado seja bem-sucedido (código HTTP 200, no entanto, errorType será definido como 'obsoleto'). Possivelmente uma estratégia razoável para fornecer aos clientes consumidores a oportunidade de conhecer um método descontinuado na API sem causar interrupção.

https://developer.foursquare.com/overview/responses

De acordo com as diretrizes da API, sugira uma data ou número da versão de compilação em que a API descontinuada será removida completamente. À medida que aprimora sua estratégia de descontinuação, você deseja alertar os consumidores da API sobre qual é a estratégia proposta (como eles podem descobrir métodos descontinuados, como fazer a transição para a API de substituição e quando a API descontinuada não estará mais disponível se removidos durante a limpeza da API) e solicite feedback deles para garantir que o processo seja benéfico para todos.

A versão da sua API é outra possibilidade. Quando uma nova versão é implantada, deixe a versão antiga ativa também e permita a negociação por meio da solicitação. Se você mantiver as versões 2 ou 3 mais recentes, o código da interface do usuário poderá atualizar no seu próprio ritmo.

Há pelo menos três perguntas ao mesmo tempo, vamos fazer uma por uma

• "é uma boa ideia ter uma biblioteca cliente para o serviço REST?"

Provavelmente sim, desde que você não deseje chamadas REST arbitrárias espalhadas diretamente por todo o seu código de interface do usuário.

• "é uma boa ideia deixar o desenvolvedor da camada de serviços criar e manter a lib?"

Isso depende das pessoas da sua equipe. O mantenedor da API deve conhecer os dois itens disponíveis na camada de serviços e os requisitos da camada de interface do usuário. Portanto, pode ser uma pessoa da camada de serviços ou uma da camada da interface do usuário ou (dependendo do tamanho e de outras tarefas) uma pessoa independentemente de ambas as equipes.

• [obteremos uma vantagem do fato de que] "se a API da biblioteca do cliente for alterada, o código da interface do usuário não será compilado"

Você não disse que a interface do usuário será escrita em Python? Essa não é uma linguagem de tipo estaticamente, portanto, eu não esperaria uma interrupção imediata da compilação a partir de uma alteração na API. Suponho que você tenha entendido errado neste momento e você tenha uma API de tipo estatístico aqui - então você pode obter algumas vantagens aqui desde que a compilação não seja interrompida ao adicionar alguns novos recursos (como novos parâmetros opcionais) à API. Caso contrário, você produzirá muita sobrecarga desnecessária para sua equipe.