RESTful API 设计之：Unix 时间戳和 ISO-8601

REST API 应该以什么格式返回并接受时间戳？两种最流行的方式是 Unix 时间（或其轻微变化）或 ISO-8601。两者各有长处和短处，正如我们将要看到的一样，两者都同样受欢迎。20 个 API 的样本产生了近 50/50 的分配。因此，无论这是否具有任何说服力，人们都可以走开，知道他们在给定 Unix 时间或 ISO-8601 的情况下选择的方法是常识，不应向其他开发人员呈现陡峭的学习曲线。

Unix 时间是完全明确的。它是自 1970 年 1 月 1 日以来的秒数。它是一个数字，并且在各种格式之间转换非常简单。有关更多信息，请访问unix4lyfe，但简而言之，使用数字有很多好处。Unix 时间的好处是通常很少进行错误检查，而且通常是一个时间戳存储在数据库中，因此不需要转换。

Unix 时间的缺点是它不是人类可读的。在响应或请求被转换之前，时间戳基本上是不可理解的。虽然转换对计算机来说并不难，但对人来说却很困难，我们想编写一个其他人可以使用的 API。要解决此问题，请使用 ISO-8601。它以定义明确、人类可读的字符串格式呈现数据。这允许更轻松的开发，因为可以卷曲或针对 API 发出 HTTP GET 请求并验证时间戳。

在我看来，REST API 应该实现 ISO-8601。Unix 时间的唯一优点是与数据库之间的转换很少。我发现这种优势充其量是微乎其微的。在最坏的情况下，以 格式的字符串与yyyy-MM-dd’T’HH:mm:ssZ整数之间的转换只会增加几个周期。无法衡量 ISO-8601 的人类可读性优势。当我使用 REST API 进行开发并开始设计我的查询时，我会手动编写它们，而不必担心将时间戳转换为 Unix 时间所花费的时间可能比我使用 Unix 时间节省的时间还多。

原文链接：https://nickb.dev/blog/designing-a-rest-api-unix-time-vs-iso-8601/