Рекомендуемый формат даты для 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?

Ответы

Ответ 1

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

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

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

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

Ответ 2

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

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

Дополнительная информация в документах.

Ответ 3

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

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

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

что это сводится к: ГГГГ-ММ-ДДТГ: мм: ss.ss ± hh: мм

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

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

Ответ 4

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

Плюсы:

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

Минусы:

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

Примечания:

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

Ответ 5

Всегда используйте UTC:

Например, у меня есть компонент расписания, который принимает один параметр DATETIME. Когда я вызываю это с помощью глагола GET, я использую следующий формат, где мое имя входящего параметра - scheduleDate.

Пример:
https://localhost/api/getScheduleForDate?scheduleDate=2003-11-21T01:11:11Z