Quanti dati da un servizio web devo esporre in una biblioteca?

Question

Quanti dati da un servizio web devo esporre in una biblioteca?

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (0 voti)
#5 da (0 voti)

1

Sto lavorando a un progetto personale, una biblioteca che può accedere a previsioni meteorologiche e altri dati relativi alle condizioni meteorologiche.

Tuttavia, molti dei dati restituiti sono talvolta del tutto ridondanti o semplicemente non hanno senso avere determinati dati all'interno di quel particolare elemento XML, ecc. Considera questi dati XML che ottengo dal servizio, che contiene le previsioni orarie:

<hour>20</hour> 
<hour_padded>20</hour_padded>
<min>00</min>   
<min_unpadded>0</min_unpadded>  
<sec>0</sec>
<year>2015</year>
<mon>3</mon>
<mon_padded>03</mon_padded>  
<mon_abbrev>Mar</mon_abbrev>   
<mday>21</mday>    
<mday_padded>21</mday_padded>    
<yday>79</yday>    
<isdst>0</isdst>    
<epoch>1426968000</epoch>    
<pretty>8:00 PM GMT on March 21, 2015</pretty>    
<civil>8:00 PM</civil>    
<month_name>March</month_name>    
<month_name_abbrev>Mar</month_name_abbrev>    
<weekday_name>Saturday</weekday_name>   
<weekday_name_night>Saturday Night</weekday_name_night>    
<weekday_name_abbrev>Sat</weekday_name_abbrev>   
<weekday_name_unlang>Saturday</weekday_name_unlang>    
<weekday_name_night_unlang>Saturday Night</weekday_name_night_unlang>    
<ampm>PM</ampm>

Come puoi vedere, c'è un lotto di dati che probabilmente non ti servono, perché puoi calcolare / convertire le informazioni su data / ora in una semplice DateTime , ecc. Un'altra serie inutile dei campi sono quelli "imbottiti". Esistono molti altri esempi di questa ridondanza con altri tipi di dati meteorologici.

Quindi, come dovrei avvicinarmi a questo, avere letteralmente ogni campo nell'XML disponibile per l'utente della libreria, o limitarti ad avere solo le parti che hanno senso a disposizione dell'utente? Mi sto appoggiando solo alle parti che hanno senso, ma volevo chiedere il parere degli altri.

c# api .net libraries web-services

posta user9993 21.03.2015 - 19:05

fonte

5 risposte

Leggi altre domande sui tag c# api .net libraries web-services

Ereditarietà rispetto al diagramma di classe [chiuso] In che modo un team di una persona trarrebbe vantaggio da una configurazione di integrazione continua? [duplicare]

score 2 · Answer 1

Seguirò il principio YAGNI e rifletterò attentamente su ciò di cui il cliente ha bisogno dalla sua parte.

Includere le cose che pensi che il cliente avrà bisogno è un sintomo di un problema centrale - ovvero la mancanza di ricerca e / o conoscenza di ciò di cui il cliente ha realmente bisogno.

score 1 · Answer 2

Se lo scopo della tua API è solo quello di fornire dati (che è vero secondo me), quindi non restituire valori ridondanti o formattati.

Nel tuo esempio, la restituzione di una singola data / ora è sufficiente. Ciò rende la tua risposta più concisa e meno ambiziosa.

Fare ipotesi sulla GUI e sull'interpretazione dei consumatori di dati forniti di solito è sbagliato approccio, evitare.

score 1 · Answer 3

La tua biblioteca è un'ape meteorologica che utilizza i servizi web esistenti per ottenere dati?

In questo caso dovresti probabilmente nascondere i dettagli degli effettivi e definire il tuo set di attributi per i dati meteo. In questo modo incapsuli la dipendenza esterna dagli utenti della API.

Potresti anche voler vedere come ottieni i dati dal xml. Cerca di associare il tuo codice solo agli elementi / tag specifici di cui hai effettivamente bisogno. Questo ti dà un po 'di compatibilità diretta nel caso in cui i tag vengano aggiunti allo schema ws xml. Se serializzi tutto l'xml in una classe (ad esempio aggiungi un riferimento al servizio), crei un accoppiamento molto più grande.

score 0 · Answer 4

Come altri hanno già detto, dovresti restituire solo una singola rappresentazione di ciascun valore. È semplicemente più semplice e facile per tutti. Come formattare quei valori per la visualizzazione dipende dalla logica della presentazione, non dalla logica del servizio. Se la formattazione di un valore dateTime o il riempimento di un intero con zeri è troppo difficile per la logica di presentazione da eseguire da solo, qualcosa è seriamente sbagliato con qualsiasi framework / linguaggio che il client utilizza per quella logica.

Ma le altre risposte in realtà non si rivolgono alla quale rappresentazione da selezionare. Quindi volevo aggiungere che dovresti scegliere una rappresentazione che:

Contiene tutte le informazioni effettive. Ad esempio, il mese dovrebbe essere lì da qualche parte, ma non in dieci modi diversi di specificarlo.
Utilizza la rappresentazione più semplice / più concisa quando esistono più opzioni. Ad esempio, se si utilizza l'orologio a 24 ore, non è necessario un campo AM / PM. Questo è così banale da aggiungere nel codice clientide che semplicemente non vale la pena complicare la tua API.
È un oggetto strutturato piuttosto che una stringa. Altrimenti tutti i client devono scrivere le utilità di analisi prima che possano iniziare sulla formattazione effettiva. (Eccezionale eccezione per i formati standard e ampiamente utilizzati come ISO 8601, eccezionalmente facili da analizzare e con molti parser già disponibili. Infatti, restituire una singola stringa ISO 8601 potrebbe essere l'ideale per te.)
O evita i problemi di localizzazione in modo completo o esplicito. Con questo intendo, sia il mese / giorno della settimana / etc sono rappresentati da numeri / enum, o le vostre richieste di servizio hanno tutti un parametro di lingua in modo che possano restituire stringhe localizzate correttamente. Qualunque sia la tua scelta, sii coerente.

Infine, se esiste una ragione legittima per cui stai facendo la formattazione nel tuo servizio (ad esempio, stai generando un file .pdf con una tabella contenente tremila valori dateTime), allora al client dovrebbe essere richiesto di fornire un formato specificatore nella loro richiesta, e questo deve essere documentato molto accuratamente. E la cosa di localizzazione si applica di nuovo.

score 0 · Answer 5

Probabilmente vorrai esporlo in un formato facilmente consumabile come un timestamp e lasciare che il consumatore scelga come interpretarlo. Qualcos'altro che potrebbe aiutare è presumere che questo è ciò che la tua API restituisce e tenta di codificarlo in un paio di casi d'uso diversi. Se ti senti disordinato, prova a restituire i dati in un formato diverso e vedere se diventa più facile da usare.