Czy interfejs API REST powinien być w stanie konwertować datę / godzinę na odpowiednią strefę czasową klienta?

10

Podczas wdrażania naszego API pojawiła się kwestia czasu i stref czasowych.

Wszystkie daty są znormalizowane do UTC w bazie danych. Obecnie w aplikacji innej niż API wszystkie czasy danych są konwertowane na podstawie preferencji użytkowników, zanim zostaną przedstawione.

Teraz pojawiło się to samo pytanie dotyczące interfejsu API: czy interfejs API powinien być w stanie zwrócić datę / godzinę odpowiednią dla strefy czasowej na podstawie semantyki żądań?

Na przykład GET /posts?timezone=America/Sao_Paulo?

A może należy to nadal robić na dowolnym kliencie uzyskującym dostęp do interfejsu API?

Aktualizacja: odkąd pojawił się kilka razy: obecnie zwracane są znaczniki czasu ze strefą czasową (chociaż zawsze jest to przesunięcie TZ +00:00). Format to popularny 8601:2015-10-29T23:00:49+00:00

rest api time

— znak
źródło

Jeśli zwrócisz znacznik czasu zawierający strefę czasową, klient może łatwo przekonwertować go na niezbędny czas lokalny. W każdym razie to pytanie nie wydaje się być związane z REST. Istnieje wiele sposobów na wdrożenie tego, które nie naruszają zasad REST. Pamiętaj, że ujawnienie tego parametru oznacza dla Ciebie więcej pracy. W architekturze naprawdę opartej na ODPOWIEDZIALNOŚCI musisz w jakiś sposób sprawić, by te linki były wykrywalne. Uderza mnie to jako niepotrzebnie skomplikowaną rzecz do wdrożenia zarówno po stronie klienta, jak i serwera.

— toniedzwiedz

> Uderza mnie niepotrzebnie skomplikowana rzecz do wdrożenia zarówno po stronie klienta, jak i serwera. Dzięki za wkład!

— zaznacz

17

Powinieneś zwrócić bezwzględny punkt w czasie, wtedy każdy może zlokalizować ten znacznik czasu w razie potrzeby. Przez „absolutny znacznik czasu” rozumiem znacznik czasu UNIX lub znacznik czasu czytelny dla człowieka, który obejmuje strefę czasową w jednym ze standardowych formatów ISO, np. „2007-04-05T14: 30Z”. W razie potrzeby klient może to w prosty sposób przekształcić w lokalną strefę czasową.

Jeśli chcesz zaakceptować parametr strefy czasowej i zlokalizować znacznik czasu w tej strefie czasowej, to jest w porządku, ale nadal powinieneś używać absolutnego znacznika czasu włącznie. strefa czasowa w odpowiedzi, np. „2007-04-05T16: 30-02: 00”. Biorąc pod uwagę, że ta wartość jest identyczna z poprzednią niezlokalizowaną, dość wątpliwe jest, dlaczego mielibyście trudności z oferowaniem tego parametru. Dokładny format wyświetlania znacznika czasu jest ostatecznie zgodny z interfejsem klienta, więc prawdopodobnie i tak przetworzy wartość.

— deceze
źródło

4

„dość wątpliwe, dlaczego miałbyś przeżywać ten problem” - jeśli nic innego, to cienki koniec klina. Następny klient tego interfejsu API może poprosić Cię o podanie strftimeformatu (plus ustawienia regionalne, dla nazw miesięcy / dni) z tych samych powodów, dla których pierwszy klient uznał, że warto określić strefę czasową. Nawet jeśli strefa czasowa jest jedyną ustępstwem, uczyniłeś odpowiedź interfejsu API bardziej złożoną: nie jest to już tylko „znacznik czasu w tym samym formacie za każdym razem”, ale „znacznik czasu wyrażony w sposób, w jaki zostałem poproszony o jego wyrażenie”

— Steve Jessop

3

Dokładnie, złożoność. Złożoność jest zła. Sprawia, że wszyscy pracują ciężej bez żadnej wartości dodanej dla produktu lub firmy. Śmierć tysiącem kawałków papieru.

— Brandon

2

> Powinieneś zwrócić bezwzględny punkt w czasie Wyjaśniłem moje pytanie, że już to robię. Dzięki za wgląd!

— zaznacz

4

Jeśli masz już logikę konwertowania wartości daty i godziny na lokalną strefę czasową użytkownika, możesz zaoferować obie możliwości w interfejsie API.

Jeśli klient złoży takie żądanie GET /posts, otrzyma cały czas w domyślnej strefie czasowej (UTC).
Jeśli klient złoży takie żądanie GET /posts?timezone=America/Sao_Paul, wówczas wszystkie czasy w odpowiedzi zostaną dostosowane do określonej strefy czasowej.

To od klienta zależy, czy chce on zrobić to w strefach czasowych.

— Bart van Ingen Schenau
źródło

2

Zwykle można oczekiwać UTC od interfejsu API.

Jeśli jednak „interfejs API REST” jest tylko częścią strony po stronie serwera przy użyciu frameworku javascript. Argumentowałbym, że w rzeczywistości zwracasz ViewModel, więc powinien on zawierać zlokalizowane ciągi, liczby i czasy.

— Ewan
źródło

2

To zły, zły, zły pomysł. Rozważ sytuację, w której klient przechowuje odpowiedzi z serwera, a następnie użytkownik podróżuje do innej strefy czasowej. Teraz masz sytuację, w której ta „funkcja” w najlepszym wypadku nie da ci żadnej przewagi ani nie spowoduje ogromnych kłopotów.

BTW. Przez ile stref czasowych i ilu klientów zamierzasz to przetestować? Jeśli serwer udzieli oczekiwanej odpowiedzi dla America / Sao_Paulo, co odpowie na America / Sao_Paulo?

— gnasher729
źródło

To był błąd z mojej strony, poprawiłem to America/Sao_Paulo. Wydaje mi się, że dyskusja dotyczy tego, co się stanie, jeśli nie będzie można zidentyfikować strefy czasowej; albo dlatego, że jest to po prostu źle, albo baza danych TZ jest nieaktualna (uważam, że ta ostatnia jest mało prawdopodobna w przypadku rzeczywistych nazw [ale nie w przypadku wartości przesunięcia). Jednak w obu przypadkach prawdopodobnie zwróciłbym 400 BAD_REQUESTodpowiedź.

— zaznacz