Design da API de serviço de dados

5

Estamos projetando um serviço de dados que armazenará um grande número de estatísticas sobre estoques, incluindo dados históricos. O cliente será um aplicativo da web, que precisará extrair vários bits de dados para mostrar em diferentes locais do site.

Como os diferentes locais precisam mostrar diferentes conjuntos de estatísticas, não é sensato que o serviço ofereça apenas um método que recupere todos os dados que temos. Como existem muitos tipos diferentes de estatísticas, o serviço não está ciente do tipo de cada um deles e simplesmente os armazena por chave.

Anteriormente, tentamos lidar com isso tendo vários métodos que retornavam objetos de dados com níveis variados de detalhes, por exemplo getBasicStockInfo, getStockInfo, getFeaturedStockInfo, getStockDetails. O problema que eu encontrei com isso foi que se tornou tedioso adicionar novos itens de dados aos objetos (precisa mudar o código do servidor), e cada um deles ficaria inchado com o tempo, à medida que campos fossem adicionados para alguns locais específicos no front end. Por outro lado, seria impraticável ter um método para cada local no front-end que retorne os dados específicos necessários nesse local.

Alguém tem alguma idéia de como lidar melhor com essa situação?

Uma coisa que estou considerando é que o cliente teria que enviar uma lista de chaves de dados para os dados desejados e receber um mapa das estatísticas. Não tenho certeza se esse é o caminho a seguir, já que o peso dos parâmetros ficaria muito pesado, com os mesmos sendo repetidamente transmitidos de cada local no aplicativo da Web.

    
por rwm 03.08.2012 / 17:44
fonte

1 resposta

1

Sua situação parece muito semelhante à forma como o SalesForce.com criou suas "chamadas principais" ( link ).

Eles transformaram todos os objetos de "dados" em uma extensão de um objeto base, de modo que eles pudessem criar facilmente um novo, reutilizando os mesmos métodos.

    
por 07.08.2012 / 19:27
fonte