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

Question

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

Плюсы:

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

Минусы:

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

Примечания:

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