Múltiplas APIs ou uma API com um parâmetro “chooser”?

5

Digamos que você tenha um serviço da web, que adiciona lógica de negócios sobre uma fonte de dados. O que cada API deste serviço parece bastante é - dado um conjunto de restrições, me dê os itens da fonte de dados que satisfaçam essas restrições. Você pode dizer que recebe uma "visualização" da fonte de dados da API.

Agora, com o tempo, você é solicitado a retornar diferentes tipos de visualizações sobre a fonte de dados. Você tem a opção de adicionar novas APIs para cada visualização "suficientemente distinta" ou para alternar as marchas e fornecer uma API getFooDataView (), que usa um parâmetro que especifica o tipo de visualização desejado. Você tem várias pressões concorrentes para decidir qual caminho seguir:

  • O grande cliente existente de seu serviço preferiria ser preguiçoso e não precisar codificar novas APIs quando novas visualizações sobre os dados forem necessárias.
  • Mas, alguns dos seus parâmetros de solicitação (restrições) só fazem sentido para algumas exibições, e não para outras - você teria que tornar seu contrato de API mais flexível dizendo "bem, se quiser ver XYZ, definindo" foo " parâmetro não terá efeito ", com o efeito colateral infeliz que você não pode fazer" foo "um parâmetro necessário, mesmo que seja assim para algumas das vistas.
  • Está se tornando cada vez mais o caso de novos clientes quererem alavancar seu serviço. Você não pode decidir o que seria mais confuso para eles - ter que escolher entre APIs diferentes, mas mais definidas, e uma API onde eles precisam saber qual combinação de parâmetros realmente dá a eles o que eles querem.

Para destilar isso, quando você desenha a linha de que algo deveria ser sua própria API, em oposição a uma variação de uma API existente? Diferentes pessoas com as quais você tem que trabalhar têm visões diferentes sobre o que torna duas solicitações de clientes semanticamente distintas, de modo que pode ser difícil obter consenso sobre esse assunto. Você também quer ter certeza de que seu serviço não é proibitivamente difícil de consumir para futuros clientes. Quais são algumas das melhores práticas para fazer esse tipo de escolha?

    
por RuslanD 20.11.2013 / 22:56
fonte

1 resposta

3

Pessoalmente, gostaria de me inclinar para APIs menores e mais estreitas. Eu não acho que segue-se que ter uma API de tamanho único faz algo mais simples de usar - na verdade, talvez o inverso, já que você precisa descobrir a combinação certa de "ju-ju" fracamente digitado para obter o que você quer, enquanto uma API mais rígida pode se tornar mais auto-explicativa. Você está apenas escondendo a complexidade em vez de explicitar isso.

Também é provável que sua API se torne cada vez mais complexa, pois envolve cada vez mais funcionalidades, enquanto as APIs mais rígidas permanecem focadas e enxutas.

Isso é um Princípio de Segregação de Interface em uma escala maior.

Sempre há outras maneiras (como uma boa orientação) para ajudar os clientes a escolher a abordagem correta.

    
por 20.11.2013 / 23:40
fonte