REST GET APIの推奨日付形式

105

このようなREST GET APIの推奨タイムスタンプ形式は次のとおりです。

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

実際の日付形式はYYYY-MM-DDThh:mm:ssZ、UTC時間などのISO 8601形式にする必要があると思います。

次のように、ハイフンとコロンのないISO 8601バージョンを使用する必要があります。

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

または、たとえばbase64エンコーディングを使用して、ISO 8601形式をエンコードする必要がありますか？

http  url  rest  date  get 
— ロレンツォポリドリ
ソース
なぜISO 8601形式がそのままではないのですか？
— ヨハネス
@Johannes ISO 8601形式（ハイフンとコロンのないバージョン）で問題ありません。URLで日付を表すためのある種の推奨されるアプローチがあるかどうか疑問に思っていました
— Lorenzo Polidori

回答:

77

RESTには推奨日付形式がありません。実際には、エンドユーザーとシステムに最適なものに要約されます。個人的には、ISO 8601（エンコードされたURL）のような標準にしたいと思います。

醜いURIがないことが問題である場合（たとえば、URLエンコードされたバージョンが含まれていない:、-、あなたの中にURI）と（人間）のアドレス指定が重要として、あなたはまた、エポック時間（例えば検討することもできませんhttp://example.com/start/1331162374）。URLは少しすっきりしているように見えますが、読みやすさは確かに失われます。

の /2012/03/07はよく目にする別の形式です。あなたは私が思うことをさらに拡張することができます。この方法を使用する場合は、常にGMT時刻になっていることを確認し（ドキュメントでそれを明確にしてください）、または何らかのタイムゾーンインジケーターを含めることもできます。

結局のところ、それはAPIとエンドユーザーに何が機能するかということになります。あなたのAPIはあなたのためではなくあなたのために働くはずです;-)。

— Nategood
ソース
12
ありがとう、非常に役立つ答え。私http://api.example.com/start_date/YYYYMMDDThhmmssZは、読みやすさとクリーンなURLに優れたISO 8601の圧縮バージョン（つまり）を使用すると思います。
— ロレンツォポリドリ
7
しかし、JSONには推奨される日付形式があり、それはISO 8601です:)
— Radu Potop
@stalemate Dateオブジェクトは、デフォルトではISO形式の日付を含む文字列としてシリアル化されます。developer.mozilla.org/en-US/docs/JSON
— Radu Potop
5
@RaduPotopはい、ただし、これは私たちが話しているHTTPおよびURI標準です。JSONがそれとどう関係しているのかはわかりません。
— nategood 2012
3
ハイフンはURLエンコードする必要がないことに注意してください。
— user128216
97

APIの日付と時間の5つの法則については、こちらの記事をご覧ください。

  • 法律1：日付にISO-8601を使用する
  • 法律2：あらゆるタイムゾーンを受け入れる
  • 法律＃3：UTCで保存する
  • 法律＃4：UTCで返す
  • 法律＃5：必要がない場合は時間を使わない

詳細については、ドキュメントをご覧ください。

— モハメド・イブラヒム
ソース
2
-1は、2017-11-20T11%3A00%3A00Zあまり読みにくいためです。また（IIS固有）、URL内のコロンはエンコードされていても非常に偏執的であるようです。
— Iain
2
このリンク-agiletribe.wordpress.com/2015/06/10/jsonrest-api-handling-datesは、iso-8601形式で発生する可能性がある人間の可読性の問題を回避するために整数エポックを推奨しています。意見が異なる場合はお知らせください。
— アンディDufresne
5
ハイフンとドットはURLの予約文字ではないことに注意してください。コロンのみがURLエンコードを必要とします（en.wikipedia.org/wiki/Percent-encoding）。ISO-8601（en.wikipedia.org/wiki/ISO_8601）では、ハイフンは必須ですが、コロンはオプションです。したがって、より高い精度が必要な場合、URLで使用する正しいISO-8601バリアントはYYYY-MM-DDThhmmssZおよびYYYY-MM-DDThhmmss.mmmZです。
— Bruce Adams、
頻繁にリンクされ、激しく議論されている記事。文字列でなければならない場合の並べ替え可能な形式の選択には同意しますが、UNIXタイムスタンプ（記事では認められていません）には、記載されている利点などすべてがあります。プレゼンテーションまで、タイムゾーンと夏時間の問題（および政治的決定）は存在しません。
— kaay
18

RFC6690-Constrained RESTful Environments（CoRE）Link Formatは、どの日付形式がセクション2にあるかを明示的に述べていませんが、リンク形式はRFC 3986を指します。これは、RFC 3986の日付タイプの推奨事項を意味しますを使用する必要が。

基本的に、インターネット上のRFC 3339の日付と時刻は、次のように見ている文書です。

グレゴリオ暦を使用して日付と時刻を表すためのISO 8601標準のプロファイルである、インターネットプロトコルで使用する日付と時刻の形式。

これは何に要約されますか： YYYY-MM-DDTHH：MM：SS.SS±HH：MM

（例：1937-01-01T12：00：27.87 + 00：20）

最も安全な賭けです。

— マタス・ヴァイトケビキウス
ソース
12

入力/出力のすべての日時フィールドはUNIX /エポックである必要があります形式ます。これにより、APIのさまざまな側面にわたる開発者間の混乱を回避できます。

長所：

  • エポック形式にはタイムゾーンがありません。
  • エポックの形式は1つです（Unix時間は1つの符号付き数値です）。
  • エポック時間は夏時間の影響を受けません。
  • ほとんどのバックエンドフレームワークとすべてのネイティブios / android APIは、エポック変換をサポートしています。
  • ユーザーのデバイス/ブラウザのタイムゾーン設定に応じて、アプリケーション側で完全にローカル時間変換部分を実行できます。

短所：

  • データベースにUTC形式で格納するためにUTCに変換するための追加処理。
  • 入力/出力の読みやすさ。
  • GET URLの読みやすさ。

ノート：

  • タイムゾーンはプレゼンテーション層の問題です！ほとんどのコードはタイムゾーンや現地時間を処理するべきではなく、Unix時間を渡しているはずです。
  • 人間が読める時間（ログなど）を保存する場合は、Unix時間ではなく、Unix時間と一緒に保存することを検討してください。
— ミトゥン・スリードハーラン
ソース
1
これ以上同意できませんでした。
— Jorge.V
1
私がこれに追加する唯一のものは、システムの任意の場所でミリ秒を考慮する必要があるかどうかを最初から検討することです。その場合は、ミリ秒バージョンのUnixタイムスタンプを使用してください。
— jamesjansson
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.