Resposta adequada à solicitação HTTP quando são solicitados muitos dados

Estou criando uma API para uma plataforma de veiculação de anúncios que permitirá que você solicite dados do rastreador para campanhas publicitárias. As campanhas costumam exceder centenas de milhões de solicitações, o que significa que haverá muitos terabytes de dados. Portanto, precisamos impedir que os consumidores da API solicitem muitos dados de uma só vez (de modo que a solicitação atinja o tempo limite), mas não tenho certeza de qual é a melhor prática.

As opções que eu já identifiquei são:

1. adicione um parâmetro extra à solicitação que indica qual seção dos dados é desejada
2. truncar os dados e, de alguma forma, informar ao cliente que eles precisam usar filtros mais específicos
3. responda com o código de status HTTP 413 (mas isso parece ser para grandes organismos de solicitação, não para respostas)
4. alternando para uma API de streaming (como as APIs de streaming do twitter )

Mas minha pergunta é: qual é a prática padrão / resposta adequada para esse tipo de situação?

Nota: Os ataques de DoS não são uma grande preocupação, pois essa não será uma API pública

Retorne o resultado mais difícil e hostil possível no caso de uma solicitação malformada (uma que retorna mais dados do que sua medição permitida está malformada). Sugiro retornar um código de erro de 4 **. Em seguida, forneça também parâmetros de paginação, para que os usuários possam solicitar páginas. oData possui esse recurso, por exemplo. Não trunque os dados silenciosamente, sob nenhuma circunstância.

Consultar os clientes é uma má ideia. Eles vão pedir para você fazer o possível para minimizar os erros, o que é uma péssima abordagem de engenharia. Esta é sua decisão, tome-a pelos chifres e faça a coisa certa.

Um exemplo de uma API paginada é oData:

http://www.odata.org/documentation/odata-version-2-0/uri-conventions/

Para expandir o que a @ joshin4colours disse, acho que você tem uma falsa dicotomia (tricotomia?). Por que não fornecer todas as três soluções? Talvez o padrão seja retornar um 413, mas com outros sinalizadores, você pode obter o que deseja com um erro incorporado nos dados e / ou fornecer uma maneira de agrupar os dados.

Realmente depende do que seu cliente / consumidor específico da API espera e como ele deseja usar sua API. Eles vão querer um 413? A resposta padrão deve incluir alguns dados e indicar quanto mais há? Talvez. Você também pode se colocar no lugar do cliente e pensar no que ele gostaria, isto é, o que seria útil para ele.

O que geralmente faço é fornecer ao primeiro lote de dados uma idéia de quanto mais existe. Retornar um 413 não é muito amigável, mas talvez seja o que você deseja em alguns casos. Pelo que experimentei, geralmente há um tamanho de lote padrão, mas as pessoas podem solicitar um determinado tamanho de lote até um certo limite.

Além disso, você pode considerar agregação ou amostragem para reduzir o tamanho do lote. Por exemplo, quero 50.000 resultados como uma amostra aleatória de 5.000.000 de registros correspondentes. Existem diferentes maneiras de cortar e cortar dados, dependendo de quão estatisticamente significativo você deseja que seus resultados sejam.

Não temos certeza das melhores práticas, mas, no nosso caso, temos parâmetros em nossa API que são configurados com algum tipo de valor máximo (pense em Integer.MAX_VALUE de Java). Esses parâmetros geralmente não estão disponíveis para a interface do usuário / cliente do aplicativo, apenas para chamadas do servidor.

Basicamente, a abordagem seria definir o máximo de registros retornados por sua solicitação. Parece funcionar bem, principalmente quando os dados não precisam ser organizados ou paginados de forma alguma.

Se um cliente (humano ou não) precisar de mais do que esse máximo, convém aumentá-lo ou agrupar seus dados de alguma forma.