it-swarm.com.ru

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

Каков рекомендуемый формат метки времени для API REST GET, например:

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?

77
Lorenzo Polidori

REST не имеет рекомендуемого формата даты. На самом деле все сводится к тому, что лучше всего подходит для вашего конечного пользователя и вашей системы. Лично я хотел бы придерживаться такого же стандарта, как у вас, для ISO 8601 (кодированный URL).

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

/2012/03/07 - это еще один формат, который вы часто видите. Вы могли бы расширить это, я полагаю. Если вы идете по этому пути, просто убедитесь, что вы либо всегда находитесь в GMT (и укажете это в своей документации), либо вы можете также включить какой-то индикатор часового пояса.

В конечном итоге все сводится к тому, что работает для вашего API и вашего конечного пользователя. Ваш API должен работать для вас, а не для вас ;-).

61
nategood

Проверьте эту статью для 5 законов даты и времени API ЗДЕСЬ :

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

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

66
mohamed-ibrahim

RFC6690 - Формат ссылки в ограниченных средах RESTful (CoRE) В явном виде не указано, какой формат даты должен быть в раздел 2. Формат ссылки он указывает на RFC 3986. Это подразумевает, что рекомендация для типа даты следует использовать RFC 3986 .

В основном RFC 3339 Дата и время в Интернете это документ, на который нужно посмотреть, в котором говорится:

формат даты и времени для использования в интернет-протоколах, который является профилем стандарта ISO 8601 для представления даты и времени с использованием григорианского календаря.

к чему это сводится: ГГГГ-ММ-ддТЧЧ: мм: сс.сс ± чч: мм

(например, 1937-01-01T12: 00: 27,87 + 00: 20)

Это самая безопасная ставка.

10
Matas Vaitkevicius

Каждое поле даты/времени во вводе/выводе должно быть в формате NIX/Epoch. Это позволяет избежать путаницы между разработчиками разных сторон API.

Плюсы:

  • Формат эпохи не имеет часового пояса.
  • Эпоха имеет единый формат (время Unix - однозначное число со знаком).
  • Время не зависит от летнего времени.
  • Большинство Backend-фреймворков и все нативные API ios/Android поддерживают преобразование Epoch.
  • Часть преобразования местного времени может быть полностью выполнена на стороне приложения, в зависимости от настройки часового пояса устройства/браузера пользователя.

Минусы:

  • Дополнительная обработка для преобразования в UTC для хранения в формате UTC в базе данных.
  • Удобочитаемость ввода/вывода.
  • Читаемость GET URL.

Примечания:

  • Часовые пояса - это проблема уровня представления! Большая часть вашего кода не должна иметь дело с часовыми поясами или местным временем, а должна проходить вокруг времени Unix.
  • Если вы хотите сохранить удобочитаемое время (например, журналы), рассмотрите возможность сохранения его вместе со временем Unix, а не со временем Unix.
5
Mithun Sreedharan