REST GET API的推荐日期格式

Question

什么是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格式进行编码？

Answer 1

检查本文为5个法律API的日期和时间的这里:

• 法律#1:在您的日期使用ISO-8601
• 法律#2:接受任何时区
• 法律#3:将其存储在UTC中
• 法律#4:以UTC格式返回
• 法律#5:如果你不需要,不要使用时间

更多信息在文档中.

Answer 2

REST没有推荐的日期格式.真的可归结为最适合您的最终用户和系统的功能.就个人而言,我希望坚持像ISO 8601(url编码)那样的标准.

如果没有丑陋的URI是一个问题(如不包括的URL编码版本:,-, in you URI) and (human) addressability is not as important, you could also consider epoch time (e.g. http://example.com/start/1331162374).URL看起来更清晰,但您肯定会失去可读性.

这/2012/03/07是你看到的另一种格式.你可以扩展我的想法.如果你走这条路,只要确保你总是处于GMT时间(并在文档中明确说明),或者你可能还想要包含某种时区指标.

最终,它归结为适用于您的API和最终用户的内容.你的API应该适合你,而不是你的;-).

Answer 3

RFC6690 - 约束RESTful环境(CoRE)链接格式在第2节中没有明确说明日期格式应该是什么.链接格式它指向RFC 3986.这意味着应该使用RFC 3986中的日期类型建议.

基本上,互联网上的RFC 3339日期和时间是要查看的文档:

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

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

(例如1937-01-01T12:00:27.87 + 00:20)

是最安全的赌注.

Answer 4

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

优点：

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

缺点：

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

笔记：

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