Un'API REST dovrebbe essere in grado di convertire datetime in timezone dei client appropriati?

Question

Un'API REST dovrebbe essere in grado di convertire datetime in timezone dei client appropriati?

#1 da (15 voti)
#2 da (4 voti)
#3 da (2 voti)
#4 da (1 voti)

9

Durante l'implementazione della nostra API, è emerso il problema dei datetime e dei fusi orari.

Tutte le date sono normalizzate in UTC nel database. Attualmente, nell'applicazione non API, tutti i dati vengono convertiti in base alle preferenze degli utenti prima di essere presentati.

Ora la stessa domanda è arrivata per l'API: l'API dovrebbe essere in grado di restituire il datetime appropriato per un fuso orario basato sulla semantica della richiesta?

es. GET /posts?timezone=America/Sao_Paulo ?

O dovrebbe ancora essere fatto su qualunque client stia accedendo all'API?

Aggiornamento: da quando è uscito un paio di volte: vengono restituiti i fusi orari con attualmente timestamp (anche se è sempre offset TZ +00:00 ). Il formato è il popolare 8601: 2015-10-29T23:00:49+00:00

api rest time

posta mark 31.10.2015 - 07:17

fonte

4 risposte

Leggi altre domande sui tag api rest time

Come consentire ai membri del team di sapere quali modifiche ho apportato a un oggetto? [chiuso] Perché è inappropriato utilizzare i diagrammi UML per pianificare come sarà organizzato il codice?

score 15 · Answer 1

Dovresti restituire un punto assoluto nel tempo, quindi chiunque può localizzare quel timestamp come necessario. Per "timestamp assoluto" intendo sia un timestamp UNIX o un timestamp leggibile dall'uomo che include il fuso orario in uno dei formati ISO standardizzati, ad es. "2007-04-05T14: 30Z". Questo può essere trasformato banalmente in un fuso orario locale dal client, se necessario.

Se vuoi accettare un parametro timezone e localizzare il timestamp su quel fuso orario va bene, ma dovresti comunque usare il timestamp assoluto incl. fuso orario nella tua risposta, ad es. "2007-04-05T16: 30-02: 00". Dato che questo valore è identico a quello precedente non localizzato, è piuttosto discutibile il motivo per cui avresti affrontato il problema di offrire questo parametro. Il formato esatto di visualizzazione del timestamp è in definitiva fino al frontend del client, quindi sarà probabilmente post-processare il valore in ogni caso.

score 4 · Answer 2

Se hai già la logica per convertire i valori datetime nel fuso orario locale dell'utente, potresti offrire entrambe le possibilità nella tua API.

Se un cliente effettua una richiesta come GET /posts , ottiene tutte le ore nel fuso orario predefinito (UTC).
Se un cliente fa una richiesta come GET /posts?timezone=America/Sao_Paul , allora tutte le volte nella risposta verrebbero adattate al fuso orario specificato.

Quindi spetta all'implementazione del cliente cosa vogliono fare con i fusi orari.

score 2 · Answer 3

Solitamente ti aspetteresti che l'UTC venga utilizzato da un'API.

Tuttavia, se la tua "API REST" è solo la parte lato server di una pagina web che utilizza un framework javascript. Direi che in effetti stai restituendo un ViewModel e quindi dovrebbe contenere stringhe, numeri e tempi localizzati.

score 1 · Answer 4

È un'idea brutta, cattiva, cattiva. Si consideri una situazione in cui il client memorizza le risposte dal server e quindi l'utente si sposta in un fuso orario diverso. Ora hai una situazione in cui questa "caratteristica" nel migliore dei casi non ti darà alcun vantaggio o creerà problemi enormi.

A proposito. Per quanti fusi orari e quanti clienti hai intenzione di testare questo? Se il server fornisce la risposta prevista per America / Sao_Paul, cosa risponderà per America / Sao_Paulo?