obter todos os dados vs obter dados parciais Otimização

Depende.

Basicamente, você precisa ver qual é a latência esperada da conexão, qual é a largura de banda e qual a capacidade de resposta desejada.

Como exemplo: suponha que a latência de ida e volta do cliente para o servidor seja de 100 ms e a largura de banda seja de 8 mb / s. Se você enviar os dados "completos" for 2Mb e os dados "parciais" forem 400kb, serão necessários 350 ms para enviar o registro "completo" e 150 msecs para enviar um registro "parcial". Se você enviar registros parciais, cada clique precisará de 110 ms para recuperar os resultados. Caso contrário, cada clique é instantâneo. Então:

• Completo - Primeiro carregamento: 350 ms, clique em: instant
• Parcial - Primeiro carregamento: 150 ms, clique em: 110 ms

O ponto chave é entender que cada chamada adiciona sobrecarga. Embora seja muito tentador minimizar os dados transferidos, isso pode realmente tornar as coisas mais lentas, se causar mais viagens de ida e volta.

É claro que isso é enganoso, porque chamadas de rede são variáveis. Mas pessoalmente com esses números eu ficaria tentado a carregar na frente.

Mas esta é apenas uma análise de alto nível. Outras coisas a considerar:

• Isso ignora completamente o custo do lado do servidor. Com que rapidez os dados "completos" são comparados com os "parciais"? Você pode puxar os dados "completos", armazená-los em cache para o futuro e retornar os dados parciais?
• O código que obtém os dados em um bloco provavelmente será mais simples no cliente e no servidor e, portanto, com menos bugs.
• Se você enviar dados parciais, precisará se preocupar com o que acontece se os registros forem alterados entre o primeiro pull e o segundo.
• Para os usuários, uma única chamada lenta seguida por uma capacidade de resposta instantânea é "mais rápida" do que se cada clique levar um tempo perceptível. Você quer prestar atenção em quão rápido os usuários acham que o sistema é o máximo possível com as caras medidas concretas de quão rápido o sistema realmente é.

Em geral, é melhor minimizar o número de chamadas de rede em vez de minimizar a quantidade de dados transferidos em geral. Mas isso não pode ser uma regra difícil e rápida porque, de fato, depende muito da largura de banda esperada e da latência esperada. Devo observar, porém, que a largura de banda está melhorando constantemente, enquanto a latência não deve melhorar significativamente com o tempo.

Você pode definir os recursos e representações da maneira adequada às suas necessidades. Eu costumo usar GET para fornecer uma visão "resumida" de uma coleção (como "... / followers") como um recurso que fornece uma lista de resumos dos seguidores, incluindo seus ids (ou URIs se eu estiver sendo bom) . Isso geralmente é suficiente para o cliente fornecer uma lista que o usuário possa procurar e, em seguida, detalhar.

No entanto, às vezes o cliente realmente quer uma lista das coisas completas. Depende apenas do seu uso. E você sempre pode fornecer um parâmetro de string de consulta (por exemplo, "? Full = true") para alternar (embora um cabeçalho de aceitação e uma negociação de conteúdo possam ser uma maneira mais "correta", mas complicada de fazê-lo). / p>

(Quanto ao aspecto de desempenho e otimização, é difícil definir um critério específico, porque isso será baseado em muitas coisas, como seu hardware, onde ele é implantado, middleware na frente de seu serviço, etc.). obviamente) enviar menos bytes será mais rápido ... além disso, você pode fazer alguns testes de desempenho para ver quais são os limites aceitáveis.)