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/