Il modo migliore per indicare più risultati disponibili

Naviga le tue risposte
3

Abbiamo un servizio per restituire i messaggi. Vogliamo limitare il numero restituito, consentendo al chiamante di specificare il numero massimo da restituire, oppure utilizzare un limite rigido interno. Abbiamo anche pensato che sarebbe bello includere nella risposta se sono disponibili più messaggi. Il modo "migliore" per farlo non è chiaro.

Ecco alcune idee finora:

  1. Imposta l'indicatore "more messages" solo se l'utente non ha specificato un limite massimo e il limite massimo interno è stato raggiunto.
  2. Come il numero 1 eccetto che è impostato l'indicatore "more messages" indipendentemente dal fatto che sia stato raggiunto il limite rigido interno o che venga raggiunto il limite specificato dall'utente.
  3. Come il numero 1 (o # 2) eccetto che internamente leggiamo limite + 1 record, ma solo i record di limite di ritorno, quindi sappiamo "di sicuro" che c'è almeno un messaggio aggiuntivo anziché "forse" ci sono altri messaggi.
  4. Elimina il contrassegno "more messages", poiché è confuso e non necessario. Invece costringere l'utente a continuare a chiamare l'API fino a quando non restituisce alcun messaggio.
  5. Cambia l'indicatore "more messages" con qualcosa di più simile a un indicatore EOF, imposta solo quando è noto che l'ultimo messaggio è stato recuperato e restituito.

Quale pensi sia la soluzione migliore? (Non deve essere una delle scelte di cui sopra.) Ho cercato e non ho potuto trovare una domanda simile già chiesto. Spero che questo non sia "troppo soggettivo".

    
posta Alex Stangl 23.04.2014 - 04:46
fonte

3 risposte

1

Di solito, aiuta a vedere come altri potrebbero aver già fatto qualcosa di simile, e vedere se può essere usato. Questo è in genere il modo in cui i modelli emergono nel software (e alcuni sono persino formalizzati come "modelli di progettazione").

Sono più familiare con oData, e in ASP.NET, oData supporta sia il lato client che il lato server . Tuttavia, spetta ai server decidere se desiderano impostare un limite superiore anche se il client ha specificato una dimensione di risposta. Ad esempio, se il client richiede un milione di messaggi, il server può ancora scegliere di limitarlo a 100 per risparmiare i costi della larghezza di banda e non incorrere in problemi di prestazioni, ecc. Quindi oData implementa il seguente modo:

  • Il cliente può specificare quanti record restituire tramite il parametro $top .
  • Client specifica anche il numero di record da saltare tramite il parametro $skip .

Pertanto, se un cliente desiderava risultati da 1 a 20, imposterebbe $top=20 e genererebbe la query. Per la pagina successiva, salta i primi 20 e quindi imposta $skip=20&$top=20 .

  • Il server può anche limitare i risultati.
  • In questo caso, nella risposta, inserisce un collegamento per la pagina successiva, utilizzando l'elemento odata.nextLink .

Pertanto, se un client ha emesso una query e non ha specificato alcun limite, il server potrebbe decidere di inviare 50 righe e quindi insieme al risultato, inviare la query per la pagina successiva: 

"odata.nextLink":"http://localhost:23645/api/Movies?$skip=50"

Impostando $skip=50 , la query successiva inizierà dall'elemento 51. Il link che ho fornito in precedenza al blog MSDN ha ulteriori dettagli.

Potresti considerare l'utilizzo di uno o entrambi questi approcci, specialmente se stai restituendo le risposte JSON. Se hai sviluppatori che vengono a utilizzare il tuo servizio, potrebbero essere più facilmente comprensibili (specialmente se hanno lavorato con oData). Oppure puoi scegliere quale sia la maggior probabilità che il framework sia noto ai tuoi sviluppatori e il modello basato su quello.

Per tua informazione, non devi necessariamente modellarli entrambi. Tuttavia, in questo caso, sembra abbastanza probabile che se riesci a modellare $top e $skip , la creazione del collegamento alla pagina successiva è piuttosto semplice se scegli di limitare il server.

    
risposta data 22.06.2014 - 09:22
fonte
0

Come consumatore di API, la mia preferenza sarebbe 3 o 5. Mentre semplifica la codifica fino a ottenere nulla, le richieste API possono essere costose. La scelta tra 3 o 5 penso sarebbe davvero scendere alla penalità per il recupero di elementi limite + 1. Se ci sono pochissime spese generali per il back-end da controllare, allora è una cosa molto amichevole far sapere all'utente prima che facciano un'altra richiesta inutile.

    
risposta data 23.04.2014 - 05:16
fonte
0

Forse puoi offrire maggiore flessibilità al cliente. La tua richiesta può avere un elemento startWith e il numero di messaggi da recuperare noOfMessages . La tua risposta può avere un campo chiamato totalMessages che terrà il numero totale di messaggi. Ciò consentirà al cliente di avere qualcosa di simile all'impaginazione. startWith verrà impostato automaticamente su zero; noOfMessages a un valore decente.

Ad esempio se hai 56 messaggi, se il cliente desidera recuperare batch di 20 secondi, possono inviare le seguenti chiamate:

Richiesta 1: 

noOfMessages: 20

Response1: 

...message list...
totalMessages: 56

Richiesta 2: 

startWith: 21
noOfMessages: 20

Richiesta 3: 

startWith: 41
noOfMessages: 16
    
risposta data 21.08.2014 - 13:17
fonte

Leggi altre domande sui tag

Come posso identificare uno spazio dei nomi senza usare una stringa letterale? Memorizzazione dei dati in elasticsearch vs mongodb