Рекомендований формат дати для REST GET API

Який рекомендований формат часової позначки для REST GET API на зразок цього:

http://api.example.com/start_date/{timestamp}

Я думаю, що фактичний формат дати має бути у форматі ISO 8601, наприклад, YYYY-MM-DDThh:mm:ssZза UTC.

Чи слід використовувати версію ISO 8601 без дефісів та колонок, таких як:

http://api.example.com/start_date/YYYYMMDDThhmmssZ

чи ми повинні кодувати формат ISO 8601, використовуючи, наприклад, кодування base64?

REST не має рекомендованого формату дати. Дійсно, це зводиться до того, що найкраще підходить для вашого кінцевого користувача та вашої системи. Особисто я хотів би дотримуватися такого стандарту, як у вас для ISO 8601 (зашифрований URL).

Якщо не мають потворні URI є проблемою (наприклад , не вмикаючи URL - адреса закодованої версії :, -, в вас URI) і адресація (людина) не так важливо, ви могли б також розглянути питання про часу доби (наприклад http://example.com/start/1331162374). URL виглядає дещо чіткіше, але ви, звичайно, втрачаєте читабельність.

/2012/03/07Ще один формат , який ви бачите багато. Ви можете розширити це, я думаю. Якщо ви йдете цим маршрутом, просто переконайтеся, що ви завжди в часі GMT (і уточніть це у вашій документації), або ви також можете включити якийсь показник часового поясу.

Зрештою, це зводиться до того, що працює для вашого API та вашого кінцевого користувача. Ваш API повинен працювати на вас, а не на нього ;-).

Перегляньте цю статтю щодо 5 законів дати та часу API тут :

• Закон №1: Використовуйте ISO-8601 для своїх побачень
• Закон №2: Прийміть будь-який часовий пояс
• Закон №3: зберігайте його в UTC
• Закон №4: Поверніть його за UTC
• Закон №5: Не використовуйте час, якщо він вам не потрібен

Більше інформації в документах.

RFC6690 - Формат посилань з обмеженими RESTful середовищами (CoRE) Не вказується чітко, який формат дати має бути, однак у розділі 2. Формат посилання вказує на RFC 3986. Це означає, що слід використовувати рекомендації щодо типу дати в RFC 3986 .

В основному, дата та час RFC 3339 в Інтернеті - це документ, який слід переглянути:

формат дати та часу для використання в Інтернет-протоколах, що є профілем стандарту ISO 8601 для представлення дат і часу за допомогою григоріанського календаря.

що це зводиться до: РРРР-MM-ddTHH: мм: ss.ss ± hh: mm

(наприклад, 1937-01-01T12: 00: 27,87 + 00: 20)

Це найбезпечніша ставка.

Кожне поле дати введення / виведення повинно бути у форматі UNIX / епохи . Це дозволяє уникнути плутанини між розробниками в різних сторонах API.

Плюси:

• Формат епохи не має часового поясу.
• Епоха має єдиний формат (час Unix - це єдиний підписаний номер).
• Час епохи не впливає на літній час.
• Більшість фреймворків Backend та всі рідні API ios / android підтримують епоху перетворення.
• Місцева частина перетворення часу може бути виконана повністю на стороні програми, залежить від налаштування часового поясу пристрою / браузера користувача.

Мінуси:

• Додаткова обробка для перетворення в UTC для зберігання у форматі UTC у базі даних.
• Читання вводу / виводу
• Читання GET URL-адрес.

Примітки:

• Часові пояси - проблема шару презентації! Більшість вашого коду не повинна мати справу з часовими поясами або місцевим часом, це має проходити час Unix.
• Якщо ви хочете зберігати читаний для людини час (наприклад, журнали), подумайте, як зберігати його разом із часом Unix, а не час Unix.

Завжди використовуйте UTC:

Наприклад, у мене є компонент розкладу, який містить один параметр DATETIME. Коли я називаю це за допомогою дієслова GET, я використовую наступний формат, де ім'я вхідного параметра є rasporedDate.

Приклад:
https: // localhost / api / getScheduleForDate? RasporedDate = 2003-11-21T01: 11: 11Z