REST GET API 的推荐日期格式 [英] Recommended date format for REST GET API

问题描述

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

What's the recommended timestamp format for a REST GET API like this:

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

我认为实际的日期格式应该是ISO 8601格式，比如UTC时间的YYYY-MM-DDThh:mm:ssZ.

I think the actual date format should be ISO 8601 format, such as YYYY-MM-DDThh:mm:ssZ for UTC time.

我们是否应该使用没有连字符和冒号的 ISO 8601 版本，例如:

Should we use the ISO 8601 version without hyphens and colons, such as:

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

或者我们应该编码 ISO 8601 格式，例如使用 base64 编码?

or should we encode the ISO 8601 format, using for example base64 encoding?

推荐答案

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

REST doesn't have a recommended date format. Really it boils down to what works best for your end user and your system. Personally, I would want to stick to a standard like you have for ISO 8601 (url encoded).

如果没有丑陋的 URI 是一个问题(例如，在您的 URI 中不包括 :、-、 的 url 编码版本)和(人类)可寻址性并不重要，您还可以考虑纪元时间(例如 http://example.com/start/1331162374).URL 看起来更简洁一些，但你肯定会失去可读性.

If not having ugly URI is a concern (e.g. not including the url encoded version of :, -, in you URI) and (human) addressability is not as important, you could also consider epoch time (e.g. http://example.com/start/1331162374). The URL looks a little cleaner, but you certainly lose readability.

/2012/03/07 是另一种您经常看到的格式.我想你可以扩展一下.如果您走这条路线，只需确保您始终处于 GMT 时间(并在您的文档中明确说明)，或者您可能还想包含某种时区指示器.

The /2012/03/07 is another format you see a lot. You could expand upon that I suppose. If you go this route, just make sure you're either always in GMT time (and make that clear in your documentation) or you might also want to include some sort of timezone indicator.

最终归结为对您的 API 和最终用户有效的方法.你的 API 应该为你工作，而不是你为它工作;-)

Ultimately it boils down to what works for your API and your end user. Your API should work for you, not you for it ;-).

这篇关于REST GET API 的推荐日期格式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！