Должен ли REST API преобразовывать дату и время в соответствующий часовой пояс клиента?

10

При реализации нашего API возникла проблема даты и времени.

Все даты нормализованы к UTC в базе данных. В настоящее время в приложении без API все даты и время конвертируются на основе предпочтений пользователей, прежде чем они представлены.

Теперь тот же вопрос возник для API: должен ли API возвращать дату и время, подходящие для часового пояса, на основе семантики запроса?

Например GET /posts?timezone=America/Sao_Paulo?

Или это должно быть сделано на клиенте, который обращается к API?

Обновление: поскольку оно появлялось несколько раз: в настоящее время возвращаются метки времени с часовым поясом (хотя это всегда смещение TZ +00:00). Формат популярный 8601:2015-10-29T23:00:49+00:00

rest api time отметка
источник
Если вы вернете метку времени, содержащую часовой пояс, клиент может легко преобразовать ее в любое необходимое местное время. В любом случае, этот вопрос, похоже, вообще не связан с REST. Существует множество способов реализовать это, которые не нарушают принципы REST. Обратите внимание, что предоставление этого параметра означает больше работы для вас. В действительно RESTful-архитектуре вам нужно как-то сделать эти ссылки доступными для обнаружения. Это кажется мне ненужной сложностью для реализации как на стороне клиента, так и на стороне сервера.
toniedzwiedz
> Мне кажется, что это слишком сложная вещь для реализации как на стороне клиента, так и на стороне сервера. Спасибо за вклад!
отметка

Ответы:

17

Вы должны вернуть абсолютный момент времени, тогда любой может локализовать эту временную метку по мере необходимости. Под «абсолютной меткой времени» я подразумеваю либо метку времени UNIX, либо метку времени, удобную для чтения человеком, которая включает часовой пояс в одном из стандартизированных форматов ISO, например, «2007-04-05T14: 30Z». При необходимости клиент может преобразовать его в местный часовой пояс.

Если вы хотите принять параметр часового пояса и локализовать временную метку для этого часового пояса, это нормально, но вы все равно должны использовать абсолютную временную метку, вкл. часовой пояс в вашем ответе, например, "2007-04-05T16: 30-02: 00". Учитывая, что это значение идентично предыдущему нелокализованному, довольно сомнительно, почему вы столкнулись с проблемой предложения этого параметра. Точный формат отображения метки времени, в конечном счете, зависит от клиентского интерфейса, так что, скорее всего, он все равно постобработает значение.

deceze
источник
4
«это довольно сомнительно, почему вы прошли через неприятности» - если ничего другого, это тонкий конец клина. Следующий клиент этого API может попросить вас указать strftimeформат (плюс языковой стандарт для названий месяцев / дней) по тем же причинам, по которым первый клиент счел полезным указать часовой пояс. Даже когда часовой пояс является единственной уступкой, вы сделали ответ своего API более сложным: это больше не просто «отметка времени в одном и том же формате каждый раз», а «отметка времени, выраженная в том виде, в котором меня попросили выразить это»
Стив Джессоп
3
Собственно, сложность. Сложность это зло. Это заставляет всех работать усерднее без какой-либо дополнительной ценности для продукта или бизнеса. Смерть от тысячи порезов.
Брэндон
2
> Вы должны вернуть абсолютный момент времени, я прояснил свой вопрос, что я уже делаю это. Спасибо за ваше понимание!
отметка
4

Если у вас уже есть логика для преобразования значений даты и времени в местный часовой пояс пользователя, вы можете предложить обе возможности в своем API.

Если клиент делает запрос как GET /posts, то он получает все время в часовом поясе по умолчанию (UTC).
Если клиент делает запрос как GET /posts?timezone=America/Sao_Paul, то все время в ответе будет настроено на указанный часовой пояс.

Затем клиентская реализация должна делать то, что они хотят делать с часовыми поясами.

Барт ван Инген Шенау
источник
2

Обычно вы ожидаете UTC от API.

Однако, если ваш «REST API» - это только часть веб-страницы на стороне сервера, использующая инфраструктуру javascript. Я бы сказал, что на самом деле вы возвращаете ViewModel, и он должен содержать локализованные строки, числа и время.

Ewan
источник
2

Это плохая, плохая, плохая идея. Рассмотрим ситуацию, когда клиент хранит ответы с сервера, а затем пользователь перемещается в другой часовой пояс. Теперь у вас есть ситуация, когда эта «функция» в лучшем случае не даст вам никаких преимуществ или создаст огромные проблемы.

КСТАТИ. Сколько часовых поясов и сколько клиентов вы собираетесь проверить это? Если сервер даст ожидаемый ответ для Америки / Sao_Paul, что он ответит для Америки / Sao_Paulo?

gnasher729
источник
Это была ошибка с моей стороны, я исправил ее America/Sao_Paulo. Я думаю, что это для обсуждения, что произойдет, если часовой пояс не может быть идентифицирован; либо потому, что это неверно, либо база данных TZ устарела (я нахожу последнее маловероятным для реальных имен [но не для значений смещения). Однако в любом случае я бы, вероятно, вернул 400 BAD_REQUESTответ.
Отметить