Un'API REST dovrebbe essere in grado di convertire il datetime nel fuso orario appropriato dei clienti?

10

Durante l'implementazione della nostra API, è emersa la questione del datetime e dei fusi orari.

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

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

Ad esempio GET /posts?timezone=America/Sao_Paulo?

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

Aggiornamento: da quando è apparso alcune volte: al momento vengono restituiti i timestamp con fuso orario (anche se è sempre offset TZ +00:00). Il formato è il popolare 8601:2015-10-29T23:00:49+00:00

rest api time

— marchio
fonte

Se si restituisce un timestamp contenente un fuso orario, il client può facilmente convertirlo in qualsiasi ora locale necessaria. Comunque, questa domanda non sembra affatto correlata al REST. Esistono numerosi modi per implementare ciò che non viola i principi di REST. Tieni presente che esporre questo parametro significa più lavoro per te. In un'architettura veramente RESTful, dovrai rendere questi collegamenti rilevabili in qualche modo. Mi sembra una cosa inutilmente complicata implementare sia sul lato client che sul lato server.

— toniedzwiedz,

> Mi sembra una cosa inutilmente complicata implementare sia sul lato client che sul lato server. Grazie per l'input!

— segna il

17

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

Se si desidera accettare un parametro fuso orario e localizzare il timestamp in quel fuso orario va bene, ma si dovrebbe comunque usare il timestamp assoluto incl. fuso orario nella risposta, ad esempio "2007-04-05T16: 30-02: 00". Dato che questo valore è identico al precedente non localizzato, è abbastanza discutibile il motivo per cui si dovrebbe affrontare il problema di offrire questo parametro. Il formato esatto di visualizzazione del timestamp dipende dal frontend del client, quindi probabilmente elaborerà comunque il valore.

— deceze
fonte

4

"è abbastanza discutibile il motivo per cui dovresti affrontare il problema" - se non altro, è la parte più sottile del cuneo. Il client successivo di questa API potrebbe chiederti di specificare un strftimeformato (più impostazioni internazionali, per i nomi di mese / giorno) per le stesse ragioni di praticità che il primo client ha trovato utile specificare un fuso orario. Anche con il fuso orario come unica concessione, hai reso la risposta della tua API più complessa: non è più solo "un timestamp nello stesso formato ogni volta", è "un timestamp espresso nel modo in cui mi è stato chiesto di esprimerlo"

— Steve Jessop

3

Esatto, complessità. La complessità è malvagia. Rende tutti lavorare di più senza alcun valore aggiunto per il prodotto o l'azienda. Morte per mille tagli di carta.

— Brandon,

2

> Dovresti restituire un momento assoluto nel tempo in cui ho chiarito la mia domanda che lo sto già facendo. Grazie per la tua comprensione!

— segna il

4

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

Se un client effettua una richiesta simile GET /posts, ottiene tutte le volte nel fuso orario predefinito (UTC).
Se un client effettua una richiesta simile GET /posts?timezone=America/Sao_Paul, tutti i tempi nella risposta verrebbero adeguati al fuso orario specificato.

Spetta quindi all'implementazione del client cosa vogliono fare con i fusi orari.

— Bart van Ingen Schenau
fonte

2

Di solito ti aspetteresti UTC 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 orari localizzati.

— Ewan
fonte

2

È una cattiva, cattiva, cattiva idea. Considerare 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" nella migliore delle ipotesi non ti darà alcun vantaggio o creerà enormi problemi.

BTW. Per quanti fusi orari e quanti clienti testerai? Se il server fornisce la risposta prevista per America / Sao_Paul, cosa risponderà per America / Sao_Paulo?

— gnasher729
fonte

È stato un errore da parte mia, l'ho corretto America/Sao_Paulo. Immagino sia in discussione cosa succede se il fuso orario non può essere identificato; o perché è semplicemente sbagliato o il database TZ non è aggiornato (trovo quest'ultimo improbabile per i nomi effettivi [ma non così per i valori di offset). Tuttavia, in entrambi i casi, probabilmente restituirei una 400 BAD_REQUESTrisposta.

— segna il