it-swarm.com.de

Empfohlenes Datumsformat für REST GET API

Was ist das empfohlene Zeitstempelformat für eine REST GET API wie folgt:

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

Ich denke, das aktuelle Datumsformat sollte das ISO 8601-Format sein, z. B. YYYY-MM-DDThh:mm:ssZ für UTC-Zeit.

Sollten wir die ISO 8601-Version ohne Bindestriche und Doppelpunkte verwenden, wie zum Beispiel:

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

oder sollten wir das ISO 8601-Format codieren, z. B. mit Base64-Codierung?

82

REST hat kein empfohlenes Datumsformat. Es kommt wirklich darauf an, was für Ihren Endbenutzer und Ihr System am besten funktioniert. Persönlich möchte ich mich an einen Standard halten, wie Sie ihn für ISO 8601 (URL-codiert) haben.

Wenn es ein Problem ist, keine hässliche URI zu haben (z. B. ohne die URL-codierte Version von :, -, in Ihrer URI) und (menschlichen) Adressierbarkeit ist nicht so wichtig, Sie könnten auch die Epochenzeit berücksichtigen (z. B. http://example.com/start/1331162374). Die URL sieht ein wenig übersichtlicher aus, aber Sie verlieren mit Sicherheit die Lesbarkeit.

Das /2012/03/07 ist ein anderes Format, das Sie häufig sehen. Ich nehme an, Sie könnten das erweitern. Wenn Sie diese Route wählen, vergewissern Sie sich einfach, dass Sie entweder immer in GMT-Zeit sind (und machen Sie dies in Ihrer Dokumentation deutlich), oder Sie möchten möglicherweise auch eine Art Zeitzonenanzeige einbeziehen.

Letztendlich läuft es darauf hinaus, was für Ihre API und Ihren Endbenutzer funktioniert. Deine API sollte für dich funktionieren, nicht für dich ;-).

63
nategood

In diesem Artikel finden Sie die 5 Gesetze der API-Daten und -Zeiten HIER :

  • Gesetz Nr. 1: Verwenden Sie ISO-8601 für Ihre Daten
  • Gesetz 2: Akzeptiere jede Zeitzone
  • Gesetz 3: Speichern Sie es in UTC
  • Gesetz Nr. 4: Geben Sie es in UTC zurück
  • Gesetz Nr. 5: Nimm dir keine Zeit, wenn du sie nicht brauchst

Mehr Infos in den Dokumenten.

69
mohamed-ibrahim

RFC6690 - Constrained RESTful Environments (CoRE) -Link-Format Gibt nicht explizit an, welches Datumsformat in Abschnitt 2 angegeben werden soll. Link-Format Es verweist auf RFC 3986. Dies impliziert, dass die Empfehlung für den Datumstyp in RFC 3986 verwendet werden sollte.

Grundsätzlich ist RFC 3339 Datum und Uhrzeit im Internet das Dokument, das Sie sich ansehen sollten.

datums- und Uhrzeitformat zur Verwendung in Internetprotokollen, das ein Profil des ISO 8601-Standards zur Darstellung von Datums- und Uhrzeitangaben unter Verwendung des Gregorianischen Kalenders ist.

worauf es ankommt: JJJJ-MM-TTTHH: mm: ss.ss ± hh: mm

(z. B. 1937-01-01T12: 00: 27.87 + 00: 20)

Ist die sicherste Wette.

12

Jedes Datums-/Uhrzeitfeld in der Eingabe/Ausgabe muss im Format NIX/Epoch vorliegen. Dies vermeidet die Verwirrung zwischen Entwicklern auf verschiedenen Seiten der API.

Vorteile:

  • Das Epochenformat hat keine Zeitzone.
  • Epoche hat ein einzelnes Format (Unix-Zeit ist eine einfach signierte Zahl).
  • Die Epochenzeit wird nicht durch die Sommerzeit beeinflusst.
  • Die meisten Backend-Frameworks und alle nativen ios/Android-APIs unterstützen die Epochenkonvertierung.
  • Die lokale Zeitumrechnung kann vollständig auf der Anwendungsseite durchgeführt werden. Dies hängt von der Zeitzoneneinstellung des Geräts/Browsers des Benutzers ab.

Nachteile:

  • Zusätzliche Verarbeitung für die Konvertierung in UTC zum Speichern im UTC-Format in der Datenbank.
  • Lesbarkeit der Ein-/Ausgabe.
  • Lesbarkeit von GET-URLs.

Anmerkungen:

  • Zeitzonen sind ein Problem auf Präsentationsebene! Der Großteil Ihres Codes sollte sich nicht mit Zeitzonen oder Ortszeit befassen, sondern Unix-Zeit verbreiten.
  • Wenn Sie eine für Menschen lesbare Zeit (z. B. Protokolle) speichern möchten, sollten Sie sie zusammen mit der Unix-Zeit und nicht anstelle der Unix-Zeit speichern.
5