Che cosa è una risorsa RESTful nel contesto di insiemi di dati di grandi dimensioni, i.E. dati meteorologici?

Question

Quindi sto lavorando a un servizio web per accedere ai dati delle previsioni del tempo (10000 posizioni, 40 parametri ciascuna, valori orari per i prossimi 14 giorni = circa 130 milioni di valori).

Quindi ho letto tutto sui servizi RESTful e la sua ideologia.

Quindi ho capito che un URL sta indirizzando una risorsa.

Ma quale è una risorsa nel mio caso?

Il caso di uso comune è che si desidera ottenere i dati per un paio di parametri in un intervallo di tempo in uno o più punti. Quindi, dare chiaramente ad ogni valore il proprio URL non è pratico e comporterebbe centinaia di richieste. Ho la sensazione che il mio problema specifico non si adatti perfettamente al modello RESTful.

Aggiornamento: Per chiarire: Esistono due modelli di utilizzo del servizio. 1. Dati grezzi; righe e righe di dati per più posizioni e parametri.

2. Dati interpretati; i dati grezzi calcolati in simboli (sole nuvole &, ad esempio) e altri parametri.

Non c'è una "previsione". Diversi clienti hanno esigenze diverse per i dati.

Il motivo per cui penso che questo non rientri nel modello REST è che, mentre posso effettivamente avere una risorsa di 'previsione', devo ancora inviare molti parametri di richiesta. Quindi una semplice richiesta GET su una risorsa non funziona, finisco per inviare i dati dappertutto.

Answer 1

Così sto lavorando su un webservice per accedere ai nostri dati delle previsioni meteo (10000 posizioni, 40 parametri ciascuno, valori orari per i prossimi 14 giorni = circa 130 milioni di valori). ... Ma che cosa è una risorsa nel mio caso?

Dipende dai dettagli del dominio del problema. Il semplice fatto di avere una grande quantità di dati non è un buon motivo per evitare REST. Esistono modi intelligenti e modi stupidi per modellare ed esporre tali dati.

Come giustamente vedi, il tuo obiettivo principale a questo punto dovrebbe essere quello di capire cosa sia esattamente una risorsa. Sapendo solo abbastanza delle previsioni del tempo per seguire il Canale Meteo, non sarò di grande aiuto qui. È per gli esperti di dominio come te stesso effettuare questa chiamata.

Se dovessi spiegare in modo un po 'più dettagliato i principali concetti di dominio con cui stai lavorando, potrebbe rendere un po' più facile dare consigli specifici.

Ad esempio, una risorsa potrebbe essere Previsione. Quando le persone del tempo parlano di previsioni, quali parole continuano a venire? Quando pensi di rompere una previsione in elementi più piccoli, quali parole usi per descrivere i pezzi?

Effettua questo processo in modo ricorsivo e probabilmente sarai in grado di creare un elenco di termini importanti. Non dimenticare che questi termini possono descrivere cose o azioni. Pensa a cosa significano realmente questi termini, quali dati puoi utilizzare per modellarli, come possono essere aggregati.

A questo punto avrete la stoffa di qualcosa che potete iniziare a costruire un sistema RESTful in giro - ma non prima.

Non dimenticare che un sistema RESTful non è un dump di dati avvolto in HTTP: è un sistema hypertext-driven.

Inoltre, non dimenticare che media types sono il punto di contatto tra il tuo server ei suoi clienti. Un tipo di media è limitato dalla tua immaginazione e può modellare i set di dati di qualsiasi dimensione, se sei intelligente a riguardo. Può contenere XML, JSON, YAML, elementi binari come un filtro Bloom, o qualsiasi altra cosa funzioni per il problema.

Answer 2

Forse è possibile utilizzare la previsione come risorsa e approfondire i servizi a grana fine con xlink.

Answer 3

sarebbe possibile fare qualcosa di simile, Dal momento che hai così tanti parametri così stavo pensando se in qualche modo è possibile riferirsi ad un mix di id/parametro di combo per ridurre le dimensioni url

/WeatherForeCastService// giorno/ora

Answer 4

www.weatherornot.com/today/days/x  // (where x is number of days) 
www.weatherornot.com/today/9am/hours/h // (where h is number of hours) 

Answer 5

in primo luogo, non v'è una volta-e-per-tutti risposta giusta.

Ogni URL valido è qualcosa che ha senso interrogare, pensarli come equivalenti a fornire moduli di query per le persone che cercano i dati, che potrebbero aiutare a restringere gli scenari.

È una questione di gusto personale e probabilmente il toolkit che si utilizza, per quanto riguarda il percorso di base dell'URL e quali parametri sono codificati. Il dibattito è un po 'come il dibattito XML sul mettere i valori negli elementi rispetto agli attributi. Non è sempre un problema razionale o logicamente deciso, né tutti saranno gentili nei loro commenti sulle vostre decisioni.

Se si utilizza un back-end come Rails, ciò implica alcuni conventions. Anche se non stai usando Rails, ha senso lavorare allo stesso modo, a meno che tu non abbia una valida ragione per cambiare.In questo modo, le persone che scrivono i clienti di parlare con i servizi basati-Rails sarà trovare il vostro più facile da capire e ti consente di risparmiare sul tempo la documentazione ;-)