REST GET API的建议日期格式

像这样的REST GET API推荐的时间戳格式是什么：

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

我认为实际的日期格式应为ISO 8601格式，例如YYYY-MM-DDThh:mm:ssZUTC时间。

我们是否应该使用没有连字符和冒号的ISO 8601版本，例如：

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

还是应该使用例如base64编码对ISO 8601格式进行编码？

REST没有推荐的日期格式。实际上，归结为最适合您的最终用户和系统的东西。就个人而言，我想坚持使用像ISO 8601（URL编码）一样的标准。

如果没有丑陋的URI是一个问题（如不包括的URL编码版本:，-，你URI）和（人类）寻址并不重要，你也可以考虑划时代时间（例如http://example.com/start/1331162374）。该URL看起来更简洁一些，但是您肯定会失去可读性。

这/2012/03/07是您经常看到的另一种格式。我想你可以扩大一下。如果您走这条路，只需确保您总是处于格林尼治标准时间（GMT）时间（并在文档中清楚说明），或者您可能还想包括某种时区指示器。

最终，归结为适用于您的API和最终用户的功能。您的API应该对您有用，而不是对您有用；-)。

在此处查看有关API日期和时间的5条定律：

• 法律1：使用ISO-8601作为日期
• 法则2：接受任何时区
• 法则3：将其存储在UTC中
• 法则4：以UTC退还
• 法则5：如果您不需要时间，请不要使用时间

文档中的更多信息。

RFC6690-受约束的RESTful环境（CoRE）链接格式在第2部分中未明确说明日期格式。链接格式指向RFC3986。这意味着应使用RFC 3986中的日期类型建议。

基本上Internet上的RFC 3339日期和时间是要查看的文件，其中说：

Internet协议中使用的日期和时间格式，它是ISO 8601标准的配置文件，用于使用公历表示日期和时间。

归结为：YYYY-MM-ddTHH：mm：ss.ss±hh：mm

（例如1937-01-01T12：00：27.87 + 00：20）

是最安全的选择。

输入/输出中的每个datetime字段都必须采用UNIX / epoch格式。这避免了API不同方面的开发人员之间的混乱。

优点：

• 纪元格式没有时区。
• Epoch具有单一格式（Unix时间是单个带符号的数字）。
• 夏时制不会影响时间。
• 大多数后端框架和所有本机ios / android API支持时代转换。
• 本地时间转换部分可以完全在应用程序侧完成，具体取决于用户设备/浏览器的时区设置。

缺点：

• 转换为UTC并以UTC格式存储在数据库中的额外处理。
• 输入/输出的可读性。
• GET URL的可读性。

笔记：

• 时区是表示层的问题！您的大多数代码都不应处理时区或本地时间，而应该传递Unix时间。
• 如果要存储人类可读的时间（例如日志），请考虑将其与Unix时间（而不是Unix时间）一起存储。

始终使用UTC：

例如，我有一个包含一个参数DATETIME的日程表组件。当我使用GET动词调用它时，我使用以下格式，其中我的传入参数名称为scheduleDate。

示例：
https：// localhost / api / getScheduleForDate？scheduleDate = 2003-11-21T01：11：11Z