Risposta corretta alla richiesta HTTP quando vengono richiesti troppi dati

Question

Risposta corretta alla richiesta HTTP quando vengono richiesti troppi dati

#1 da (6 voti)
#2 da (1 voti)
#3 da (0 voti)

8

Sto costruendo un'API per una piattaforma di pubblicazione di annunci che ti consentirà di richiedere i dati del tracker per le campagne pubblicitarie. Le campagne spesso superano centinaia di milioni di richieste, il che significa che ci saranno molti terabyte di dati. Pertanto, dobbiamo impedire ai consumatori di API di richiedere troppi dati contemporaneamente (in modo tale che la richiesta scada), ma non sono sicuro di quale sia la migliore pratica per farlo.

Le opzioni che ho già identificato sono:

aggiungi un parametro aggiuntivo alla richiesta che indica quale sezione dei dati è desiderata
tronca i dati e in qualche modo comunica al cliente che è necessario utilizzare filtri più specifici
risponde con il codice di stato HTTP 413 (ma sembra essere per corpi di richieste di grandi dimensioni, non per risposte)
passaggio a un'API di streaming (come API di streaming di Twitter )

Ma la mia domanda è: qual è la pratica standard / risposta appropriata per questo tipo di situazione?

Nota: gli attacchi DoS non sono molto preoccupanti poiché questa non sarà un'API pubblica

database rest http ajax scalability

posta Griffin 03.09.2014 - 21:43

fonte

3 risposte

Leggi altre domande sui tag database rest http ajax scalability

Spingendo i dati dal server al client senza una richiesta del cliente? Algoritmo per generare N numeri casuali tra A e B che sommano a X

score 6 · Answer 1

Restituisce il risultato più duro e più sfavorevole possibile in caso di una richiesta non corretta (quella che restituisce più dati di quanti ne consente la misurazione non è corretta). Suggerisco di restituire un codice di errore 4 **. Quindi, fornire anche i parametri di paging, in modo che gli utenti possano richiedere le pagine. oData ha questa caratteristica, per esempio. Non troncare i dati in modo silenzioso, in nessuna circostanza.

La consulenza con i clienti è una cattiva idea. Vi diranno di fare tutto il possibile per minimizzare gli errori, il che è un approccio ingegneristico errato. Questa è la tua decisione, prendila per le corna e fai la cosa giusta.

Un esempio di api impaginato è oData:

link

score 1 · Answer 2

Per espandere ciò che ha detto @ joshin4colours, penso che tu abbia una falsa dicotomia (tricotomia?). Perché non fornire tutte e tre le soluzioni? Forse l'impostazione predefinita è di restituire un 413, ma con altri flag è possibile ottenere un po 'di ciò che si desidera con un errore incorporato nei dati e / o fornire un modo per raggruppare i dati.

Dipende molto da cosa si aspetta il tuo cliente / consumatore specifico dell'API e da come vogliono usare la tua API. Vorrà mai un 413? La risposta predefinita dovrebbe includere alcuni dati e indicare quanto c'è di più? Può essere. Potresti anche metterti nei panni del cliente e pensare a ciò che vorrebbero, cioè a cosa sarebbe utile per loro.

Quello che ho fatto di solito è dare la prima serie di dati con un'idea di quanto c'è di più. Restituire un 413 non è molto amichevole, ma forse è quello che vuoi in alcuni casi. Da quello che ho vissuto, di solito c'è una dimensione di batch predefinita, ma le persone possono chiedere un certo numero di batch fino ad un certo limite.

Inoltre, potresti considerare l'aggregazione o il campionamento per ridurre le dimensioni del batch. Ad esempio, voglio 50.000 risultati come un campione casuale di 5.000.000 di record corrispondenti. Ci sono diversi modi per affettare e tagliare a seconda di quanto statisticamente significativo vuoi che i tuoi risultati siano.

score 0 · Answer 3

Non sono sicuro di una best practice, ma nel nostro caso abbiamo parametri nella nostra API impostati su un valore massimo (pensate a Integer.MAX_VALUE da Java). Questi parametri spesso non sono disponibili per l'interfaccia utente / lato client dell'applicazione, solo per le chiamate lato server.

In sostanza, l'approccio sarebbe quello di impostare un massimo sui record restituiti dalla richiesta. Sembra funzionare bene, in particolare quando i dati non devono essere organizzati o impaginati in alcun modo.

Se un cliente (umano o meno) ha bisogno di più di questo massimo, potresti prendere in considerazione l'ipotesi di aumentare o mettere in batch i tuoi dati in qualche modo.