Чи повинен API REST перетворювати дату на відповідний часовий пояс клієнтів?

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. Зауважте, що показ цього параметра означає більше роботи для вас. В справжній архітектурній архітектурі вам потрібно буде якось відкрити ці посилання. Мені здається, що це непотрібно складно реалізувати як на стороні клієнта, так і на сервері.

— toniedzwiedz

> Мені здається, що це непотрібно складно реалізувати як на стороні клієнта, так і на сервері. Дякую за вклад!

— відмітка

17

Ви повинні повернути абсолютний момент часу, тоді будь-хто може локалізувати цю мітку за потребою. Під "абсолютною міткою часу" я маю на увазі або часову марку UNIX, або людську читану часову марку, яка включає часовий пояс в одному з стандартизованих форматів ISO, наприклад "2007-04-05T14: 30Z". Це може тривіально перетворюватися клієнтом на місцевий часовий пояс.

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

— обман
джерело

4

"Досить сумнівно, чому ти пережив би неприємність" - якщо нічого іншого, то тонкий кінець клина. Наступний клієнт цього API може попросити вас дозволити їм вказати strftimeформат (плюс локаль, імена місяця / дня) з тих же причин зручності, що перший клієнт вважав корисним вказати часовий пояс. Навіть якщо часовий пояс є єдиною поступкою, ви зробили відповідь API більш складним: це вже не просто "часова марка в одному форматі кожного разу", це "часова марка, виражена так, як мене попросили висловити"

— Стів Джессоп

3

Саме так, складність. Складність - зло. Це змушує всіх працювати важче без будь-якої доданої вартості товару чи бізнесу. Смерть тисячею вирізів паперу.

— Брендон

2

> Ви повинні повернути абсолютний момент у часі. Я уточнив своє питання, що я вже роблю це. Дякуємо за ваше розуміння!

— відмітка

4

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

Якщо клієнт робить такий запит GET /posts, він отримує весь час у часовому поясі за замовчуванням (UTC).
Якщо клієнт робить такий запит GET /posts?timezone=America/Sao_Paul, то весь час у відповіді буде коригуватися вказаний часовий пояс.

Тоді від клієнтської реалізації залежить те, що вони хочуть робити з часовими поясами.

— Барт ван Інген Шенау
джерело

2

Як правило, від API ви очікували UTC.

Однак якщо ваш "REST API" - це лише частина сервера на веб-сторінці, що використовує рамку javascript. Я заперечую, що насправді ви повертаєте ViewModel, і він повинен містити локалізовані рядки, числа та часи.

— Еван
джерело

2

Це погана, погана, погана ідея. Розглянемо ситуацію, коли клієнт зберігає відповіді з сервера, а потім користувач подорожує в інший часовий пояс. Тепер у вас ситуація, коли ця "особливість" у кращому випадку не дасть вам жодної переваги, або створить величезні проблеми.

До речі. Скільки часових поясів і скільки клієнтів ви збираєтеся перевірити? Якщо сервер дасть очікувану відповідь для America / Sao_Paul, що він відповість для America / Sao_Paulo?

— gnasher729
джерело

Це була помилка з мого боку, я її виправив America/Sao_Paulo. Я думаю, що для обговорення, що відбувається, якщо часовий пояс не вдасться ідентифікувати; або тому, що це неправильно, або база даних TZ застаріла (я вважаю, що останнє мало ймовірно для фактичних імен [але не так для зміщених значень). Однак у будь-якому випадку я, мабуть, поверну 400 BAD_REQUESTвідповідь.

— відмітка