REST GET API的推荐日期格式

Question

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

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

我认为实际的日期格式应该是ISO8601格式，例如UTC时间的YYYY-MM-DDThh:mm:ssZ。

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

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

或者我们应该对ISO8601格式进行编码，例如使用base64编码？

Answer 1

REST没有推荐的日期格式。实际上，它归结为最适合您的最终用户和您的系统的方式。就我个人而言，我想坚持ISO 8601 (url编码)的标准。

如果没有丑陋的URI是一个问题(例如，不包括url编码版本的:，-，in you URI)和(人的)寻址能力不是那么重要，你也可以考虑纪元时间(例如http://example.com/start/1331162374)。URL看起来更干净一些，但您肯定会失去可读性。

/2012/03/07是您经常看到的另一种格式。我想您可以在此基础上进行扩展。如果你走这条路，只需要确保你总是在GMT时间(并在你的文档中明确这一点)，或者你可能还想包括一些时区指示器。

归根结底，它取决于什么对您的API和您的最终用户有效。你的API应该为你工作，而不是为你工作;-)。

Answer 2

查看这篇文章，了解API date and time HERE的5条法则。

• 法则#1:使用ISO-8601作为您的日期
• 法则#2:接受任何时区
• 法则#3:将其存储在UTC
• 中法则#4:将其返回到UTC
• 法则#5:如果您不需要时间，请不要使用

文档中有更多信息。

Answer 3

输入/输出中的每个日期时间字段都需要为格式。这避免了API不同方面的开发人员之间的混淆。

优势：

• Epoch格式没有单一格式的timezone.
• Epoch (Unix时间是单符号数字)，
• epoch时间不受夏令时影响，
• 大部分后端框架和所有原生ios/android API都支持epoch Unix时间转换部分完全可以在应用端完成，具体取决于用户device/browser.

的时区设置

缺点：

用于转换为UTC以便以UTC格式存储在GET URL的database.

• Readability of input/output.

• Readability中的
• 额外处理。

备注：

• Timezones are a presentation-layer problem!大多数代码不应该处理时区或本地时间，它应该传递Unix时间。
• 如果您想存储人类可读的时间(例如日志)，请考虑将其与Unix时间一起存储，而不是与Unix时间一起存储。