设计一个REST API。Unix时间vs ISO-8601

Published on: February 22, 2013

发表于2013年2月22日

In what format should a REST API return and accept timestamps? The two most popular ways are Unix time (or a slight variation thereof) or ISO-8601. Both have their strengths and weaknesses and both are equally popular as we shall see. A sample of 20 APIs yielded nearly a 50/50 split. Therefore, no matter if this holds any persuasion or not, one can walk away knowing that their method of choice given Unix time or ISO-8601, is common knowledge and shouldn’t present a steep learning curve to other developers.

REST API应该以什么格式返回和接受时间戳？最流行的两种方式是Unix时间（或其轻微变化）或ISO-8601。两者都有其优点和缺点，而且正如我们将看到的那样，两者都同样受欢迎。对20个API的抽样调查产生了几乎50/50的比例。因此，不管这是否有说服力，人们可以知道他们选择的方法，即Unix时间或ISO-8601，是常识，不应该给其他开发者带来陡峭的学习曲线。

Unix time is completely unambiguous. It’s the number of seconds since January 1st, 1970. It’s a number and is extremely simple to convert to and from various formats. For more information, visit unix4lyfe, but in short, there are a lot of benefits to working with just a number. The nice thing about Unix time is that there is often little error checking and it is often a timestamp is stored in the database, so no conversion is necessary.

Unix时间是完全不含糊的。它是1970年1月1日以来的秒数。它是一个数字，并且非常简单地与各种格式进行转换。欲了解更多信息，请访问unix4lyfe，但总之，只用一个数字工作有很多好处。Unix时间的好处是，通常没有什么错误检查，而且它的时间戳往往存储在数据库中，所以不需要转换。

The downfall of Unix time is that it is not human readable. Until the response or request has been converted, the timestamp is essentially unintelligible. While the conversion isn’t hard for a computer, it is for a human, and we want to write an API that other humans consume. To fix this is ISO-8601. It presents the data in a well defined, human readable string format. This allows for easier development as one can curl or issue an HTTP GET request against the API and verify the timestamps.

Unix时间的缺点是它不能被人类阅读。在响应或请求被转换之前，时间戳基本上是不可理解的。虽然转换对计算机来说并不难，但对人类来说却很难，而且我们想写一个其他人类可以使用的API。为了解决这个问题，ISO-8601。它以一种定义良好的、人类可读的字符串格式呈现数据。这使得开发更加容易，因为人们可以对API进行curl或发出HTTP GET请求，并验证时间戳。

It is in my opinion that a REST API should implem...