Quanti dati devono essere richiesti in una richiesta a un webservice?

I maestri zen dei servizi Web direbbero:

Require the absolute minimum amount of data required to fill out the request.

Reply with as much data as might be useful to a requester.

La ragione è che i dati extra richiedono un lavoro supplementare (e non necessario) sul lato client e introduce un maggior overhead e più bug. L'invio di "troppi" dati nella risposta in genere è solo un piccolo lavoro extra per il server, non richiede alcuno sforzo per il client di ignorare i campi che non necessita attualmente e, riduce il numero di richieste di modifica a lungo termine . In questo modo la tua API sarà più facile da usare e utile per il più vasto pubblico possibile.

Fuori dalla mia testa?

• Richiedere informazioni ridondanti può ridurre (anche se in modo non certo eliminare) bug che coinvolgono errori di tipo spuri o "off-by-one". L'invio di un ordine con un codice prodotto e una descrizione del prodotto è meno probabile che si tratti accidentalmente del codice prodotto errato.
• Puoi forzare l'interazione a utilizzare la tua interfaccia completa. I web scrapers dovranno mantenere lo stato della sessione per avere informazioni sufficienti per eseguire il servizio. Ciò significa che puoi valutare il limite in modo più efficace, se questo è un problema per te.
• Non devi cercare nulla; è tutto lì nella richiesta: add_to_order(Product(**json.loads(request.data)))

Sembra logico che se si inviano dati al client, allora è sufficiente una piccola quantità di dati anziché l'intera popolazione. Tuttavia, potrebbero verificarsi casi in cui un'interfaccia viene considerata come un'operazione di salvataggio che può eseguire sia gli aggiornamenti sia gli inserimenti. Un inserto di solito richiede l'intera popolazione non viene inviato nulla al client e non ci sono valori predefiniti predefiniti.

Alcuni sviluppatori cercano di ridurre il numero di interfacce perché meno interfacce significano meno punti di guasto e costi di manutenzione ridotti. Anche se rende le cose un po 'più difficili dal lato client.

Tuttavia, con ciò detto, se le prestazioni o la larghezza di banda sono un problema, allora dovresti cercare di minimizzare la quantità di informazioni passate tra client e server.

Questo è un tipico compromesso tra prestazioni e semplicità con cui gli sviluppatori sono in difficoltà.

Nel caso in cui stiamo solo parlando di servizi dati per il recupero e la memorizzazione di oggetti entità il minimo di informazioni possibili è bello avere. Ciò consente di lavorare senza stato e offre un maggiore controllo sull'integrità dei dati (perché è tutto gestito nel livello dati).

Se tuttavia parliamo di servizi di integrazione, ad esempio, che supportano transazioni a lungo termine, il requisito per la quantità di dati post richiesti potrebbe spostarsi un po 'di più.

Situazioni in cui si potrebbe offrire un cliente un determinato prezzo per un ordine specifico potrebbe variare nel tempo e per persona di vendita, ma l'accettazione di un tale ordine potrebbe richiedere alcuni giorni. In tal caso, si desidera essere in grado di recuperare oltre l'ordine ma anche altri criteri. In tal caso, si ottengono dati aggiuntivi che forniscono un contesto sufficiente per ricostruire la situazione.

Quindi immagino che tutto dipenda dall'essere in grado di avere abbastanza informazioni disponibili per ricostruire la situazione originale e ricavare le azioni necessarie da eseguire.

Quando i dati cambiano, potrebbe essere necessario sapere se il client richiede l'operazione in base alla versione corrente. Puoi richiedere tutti i dati rilevanti per la verifica o fornire una versione / timestamp e richiederli.

Se i dati cambiano in grandi transazioni, la versione / timestamp di solito è più semplice, ma se vari bit cambiano indipendentemente, allora dovresti fornire molte versioni, quindi chiedere semplicemente i dati è più semplice.

La richiesta dovrebbe contenere informazioni essenziali solo oltre ai filtri (se applicabile). Il risultato dovrebbe contenere i dati più importanti con cui un utente può utilizzare le informazioni per prendere una decisione. La quantità di dati restituiti dovrebbe essere minima per i sistemi con un numero elevato di utenti.

Se il tuo sistema è ben progettato per servire l'azienda, è possibile farlo.

La convalida della GUI è necessaria per allinearsi alla natura aziendale in modo che la quantità di dati restituiti non sia eccessiva. Ad esempio, la ricerca per nome in una banca non dovrebbe consentire la ricerca di una singola lettera. Ottenere tutti i nomi che iniziano con "D" è una richiesta dispari che la GUI dovrebbe impedire, in modo che non vengano restituiti 100000 nomi.

Il database e le query dovrebbero essere progettati per la navigazione incrementale per servire a questo scopo.

Dovresti valutare attentamente il tipo di informazioni che il cliente deve inviare al server. A mio avviso, dovresti fornire tutta la serie di informazioni necessarie per operare solo con un servizio stateless, dall'altra lato preferisco inviare il set minimo di dati necessari se il servizio è pieno di stato.

In un servizio web di ordinazione di ordini (come descrivi) ci sono un insieme di informazioni rilevanti che dovrebbero essere conservate in una sessione dal server e non fornite dal cliente. Pensa al prezzo. Cosa succede se un client malevolo cambia il prezzo da 100 $ a 1 $?

Richiedere informazioni ridondanti al client è una minaccia alla sicurezza generale. Detto questo, non devi chiedere a un cliente di inviare quel tipo di dati. Gli altri effetti collaterali positivi di questa pratica sono che un client è più facile da implementare e che il payload trasferito è più piccolo, ma li considero effetti collaterali poiché una buona politica di sicurezza sui dati trasferiti supera tutti.

I messaggi del servizio Web devono essere pesanti, non chiacchieroni . Orientato ai messaggi, non orientato alle chiamate.

Una richiesta o un messaggio di comando dovrebbe contenere, come minimo, informazioni sufficienti per:

1. Convalidare il chiamante (autenticazione / autorizzazione).
2. Convalidare la transazione (ad esempio, una richiesta di aggiornamento in un ambiente di concorrenza ottimistico potrebbe richiedere il numero di versione originale)
3. Esegui la transazione (identificatori, parametri di ricerca, ecc.)

Inoltre, di solito ci sono molti parametri / elementi che vorrete avere come facoltativo ma non richiesto :

• Elenchi di richieste secondarie, con un ID di correlazione fornito dal cliente. Per qualsiasi operazione, non richiedere al cliente di effettuare richieste una per una; invece, consenti loro di stipare tutto in un unico messaggio e assicurati di ripetere i loro ID di correlazione nella risposta. Questo è di fondamentale importanza negli ambienti ad alta latenza. (Gli ID di correlazione dovrebbero ovviamente essere facoltativi, come la lista stessa).

• Il tipo di dati (specialmente per REST) - consente ai client di specificare XML, JSON, ecc.

• Controlla la dimensione e la forma del messaggio di risposta, specialmente se la risposta sarà molto grande e / o contiene molti elementi. Come minimo, fornire un modo per limitare il numero massimo di risultati. Le opzioni di ordinamento e paging sono migliori. Alcuni servizi, ad esempio Salesforce, forniscono anche un "ID query" che può essere utilizzato per recuperare rapidamente le pagine di un risultato.

  Se è probabile che faccia una differenza nelle prestazioni, potresti anche considerare di consentire ai client di indicare il livello di nidificazione e / o quali relazioni caricare, utilizzando un valore predefinito sensato (generalmente tutto o nessuno).

• Un indirizzo di ritorno (per i messaggi a senso unico).

• Timeout, strategie di gestione degli errori, impostazioni dei registri o qualsiasi altra cosa che potrebbe essere di particolare importanza per una transazione di lunga durata. (Ancora, usa le impostazioni predefinite e convalida gli input!)

• Alcuni servizi forniranno ai clienti un'area in cui inserire solo i dati utente desiderati, come stringa o come elemento XML. Pensa a questa come alla linea "memo" su un assegno. È particolarmente utile negli scenari di messaggistica a senso unico.

Non posso sottolineare abbastanza strong che questo secondo elenco di opzioni deve essere facoltativo e utilizzato solo per i messaggi che ne beneficiano effettivamente . Non vuoi confondere i clienti con una serie sconcertante di opzioni apparentemente inutili.

Infine, cerca di mantenere le informazioni che sono comuni a tutti i messaggi (specialmente le credenziali) nelle intestazioni, non nel corpo. Se si hanno informazioni comuni a molti messaggi ma non necessariamente tutti (l'ordinamento / paging è un esempio comune), quindi considerare di astrarlo nel proprio tipo di dati (oggetto parametro) . In questo modo il cliente può riutilizzare le stesse impostazioni più e più volte se lo desidera.

Per favore non richiedere tutti i tipi di controlli e saldi come nomi che devono corrispondere a ID, ID sessione, checksum, totali di controllo o altro. Devi fidarti dei tuoi clienti con i privilegi che hanno ricevuto. Se non ti fidi di loro di inviare dati corretti (in base ai propri requisiti), allora hai un problema commerciale da risolvere, non tecnico.