Proper GET links documentation #4
Conversation
| "api" | ||
| ], | ||
| "private": true, | ||
| "created": "2016-06-15T19:23:14+0200", |
There was a problem hiding this comment.
I'm in favor of UNIX timestamps instead which do not assume the requesting machine has such or such localized date format, and are also easier to compare/work with (they are just integers).
There was a problem hiding this comment.
plz only ISO8601 acc W3C for timestamps almost as in the example, but with timezone colon: 2016-06-15T19:23:14+02:00. UTC if you prefer. Compare trivial. Nothing else plz.
There was a problem hiding this comment.
does description need a (optional) mimetype nowadays (plaintext vs. markdown)? Atom/content does it this way.
There was a problem hiding this comment.
Regarding timestamps, I've seen funny things over some APIs, where you need to multiply or divide the value of the returned Unix epoch to avoid time-travelling either to the Dark Ages™ or to the end of all known multiverses...
ISO8601 is indeed recommended for date/time representation:
- http://stackoverflow.com/questions/9581692/recommended-date-format-for-rest-get-api
- http://apiux.com/2013/03/20/5-laws-api-dates-and-times/
@nodiscc decent programming languages propose libraries for proper date/time parsing, that developers will use when they really care about timezones and Daylight Saving Time :)
There was a problem hiding this comment.
does description need a (optional) mimetype nowadays (plaintext vs. markdown)?
Markdown content is also plaintext. Instead of adding an additional field, a service returning settings, included enabled plugins is probably better. It would let clients interpret any plugin if they want to.
what is "todo"?
I had to do this object definition. 😛
|
Indeed unix timestamps also have their own quirks. Thanks for pointing me to ISO8601, let's go with this.
|
|
Thanks for the review. I'm merging this since there is no blocking comment about it. We can come back on this in another issue/PR if we need to. |
No description provided.