รูปแบบวันที่ที่แนะนำสำหรับ REST GET API

105

รูปแบบการประทับเวลาที่แนะนำสำหรับ REST GET API เป็นอย่างไร:

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

ฉันคิดว่ารูปแบบวันที่จริงควรเป็นรูปแบบ ISO 8601 เช่นYYYY-MM-DDThh:mm:ssZสำหรับเวลา UTC

เราควรใช้ ISO 8601 เวอร์ชันที่ไม่มียัติภังค์และโคลอนเช่น:

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

หรือเราควรเข้ารหัสรูปแบบ ISO 8601 โดยใช้เช่นการเข้ารหัส base64?

http  url  rest  date  get 
— ลอเรนโซโพลิโดริ
แหล่งที่มา
เหตุใดจึงไม่ใช่รูปแบบ ISO 8601 ตามที่เป็นอยู่จึงเป็นตัวเลือกสำหรับคุณ
— Johannes
@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 ของคุณควรใช้งานได้สำหรับคุณไม่ใช่คุณสำหรับมัน ;-)

— หมวดหมู่
แหล่งที่มา
12
ขอบคุณคำตอบที่มีประโยชน์มาก ฉันคิดว่าฉันจะใช้ ISO 8601 เวอร์ชันบีบอัด (เช่นhttp://api.example.com/start_date/YYYYMMDDThhmmssZ) ซึ่งดีสำหรับการอ่านและทำความสะอาด URL
— Lorenzo Polidori
7
แต่ JSON จะมีรูปแบบวันที่แนะนำและเป็นมาตรฐาน ISO 8601 :)
— Radu Potop
5
@RaduPotop ใช่ แต่นี่คือมาตรฐาน HTTP และ URI ที่เรากำลังพูดถึง ฉันไม่แน่ใจว่า JSON เกี่ยวข้องกับอะไร
— nategood
3
ฉันแค่อยากทราบว่ายัติภังค์ไม่จำเป็นต้องเข้ารหัส URL
— user128216
1
ลิงค์นี้ - agiletribe.wordpress.com/2015/06/10/jsonrest-api-handling-dates แนะนำยุคจำนวนเต็มเพื่อหลีกเลี่ยงปัญหาความสามารถในการอ่านของมนุษย์ที่อาจเกิดขึ้นกับรูปแบบ iso-8601 แจ้งให้เราทราบหากคุณมีมุมมองที่แตกต่าง
— Andy Dufresne
97

ตรวจสอบบทความนี้สำหรับกฎหมาย 5 ข้อของวันที่และเวลาของ API ที่นี่ :

  • กฎหมาย # 1: ใช้ ISO-8601 สำหรับวันที่ของคุณ
  • กฎหมาย # 2: ยอมรับเขตเวลาใดก็ได้
  • กฎหมาย # 3: เก็บไว้ใน UTC
  • กฎหมาย # 4: ส่งคืนใน UTC
  • กฎหมาย # 5: อย่าใช้เวลาถ้าคุณไม่ต้องการ

ข้อมูลเพิ่มเติมในเอกสาร

— โมฮาเหม็ดอิบราฮิม
แหล่งที่มา
2
-1 เช่นเดียวกับ2017-11-20T11%3A00%3A00Zที่อ่านไม่ได้มาก นอกจากนี้ (เฉพาะ IIS) ดูเหมือนว่าจะหวาดระแวงเกี่ยวกับโคลอนใน URL แม้ว่าจะมีการเข้ารหัสก็ตาม
— Iain
3
ลิงค์นี้ - agiletribe.wordpress.com/2015/06/10/jsonrest-api-handling-datesแนะนำยุคจำนวนเต็มเพื่อหลีกเลี่ยงปัญหาความสามารถในการอ่านของมนุษย์ที่อาจเกิดขึ้นกับรูปแบบ iso-8601 โปรดแจ้งให้เราทราบหากคุณมีมุมมองที่แตกต่างกัน
— Andy Dufresne
5
โปรดทราบว่ายัติภังค์และจุดไม่ใช่อักขระที่สงวนไว้ใน URL เฉพาะโคลอนเท่านั้นที่ต้องการการเข้ารหัส URL ( en.wikipedia.org/wiki/Percent-encoding ) ใน ISO-8601 ( en.wikipedia.org/wiki/ISO_8601 ) จำเป็นต้องมียัติภังค์ แต่เครื่องหมายโคลอนเป็นทางเลือก ดังนั้นตัวแปร ISO-8601 ที่ถูกต้องเพื่อใช้ใน URL คือ YYYY-MM-DDThhmmssZ และ YYYY-MM-DDThhmmss.mmmZ หากคุณต้องการความแม่นยำมากขึ้น
— Bruce Adams
บทความที่มีการเชื่อมโยงและมีการถกเถียงกันบ่อยครั้ง แม้ว่าฉันจะเห็นด้วยกับการเลือกรูปแบบที่จัดเรียงได้หากต้องเป็นสตริงเลยแต่การประทับเวลาแบบยูนิกซ์ (ซึ่งบทความนี้ไม่ได้รับทราบด้วยซ้ำ) ก็มีประโยชน์ที่ระบุไว้ทุกประการและอื่น ๆ จนกว่าจะนำเสนอประเด็นของเขตเวลาและการออมแสง (และการตัดสินใจทางการเมือง) จะไม่มีอยู่จริง
— kaay
18

RFC6690 - รูปแบบข้อ จำกัด สงบสิ่งแวดล้อม (CORE) ลิงค์ไม่ชัดเจนรัฐสิ่งที่รูปแบบวันที่ควรจะเป็นอย่างไรก็ตามในส่วนที่ 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)

เป็นการเดิมพันที่ปลอดภัยที่สุด.

— Matas Vaitkevicius
แหล่งที่มา
13

ทุกฟิลด์วันที่และเวลาในอินพุต / เอาต์พุตต้องอยู่ในรูปแบบUNIX / epoch เพื่อหลีกเลี่ยงความสับสนระหว่างนักพัฒนาในด้านต่างๆของ API

ข้อดี:

  • รูปแบบ Epoch ไม่มีเขตเวลา
  • Epoch มีรูปแบบเดียว (เวลา Unix คือตัวเลขที่ลงนามเดียว)
  • ช่วงเวลาไม่ได้รับผลกระทบจากการออมแสง
  • เฟรมเวิร์กแบ็กเอนด์ส่วนใหญ่และ API ดั้งเดิมของ iOS / Android ทั้งหมดรองรับการแปลง epoch
  • ส่วนการแปลงเวลาท้องถิ่นสามารถทำได้ทั้งหมดในฝั่งแอปพลิเคชันขึ้นอยู่กับการตั้งค่าเขตเวลาของอุปกรณ์ / เบราว์เซอร์ของผู้ใช้

จุดด้อย:

  • การประมวลผลพิเศษสำหรับการแปลงเป็น UTC เพื่อจัดเก็บในรูปแบบ UTC ในฐานข้อมูล
  • ความสามารถในการอ่านอินพุต / เอาต์พุต
  • ความสามารถในการอ่าน GET URL

หมายเหตุ:

  • เขตเวลาเป็นปัญหาของเลเยอร์การนำเสนอ! รหัสส่วนใหญ่ของคุณไม่ควรเกี่ยวข้องกับเขตเวลาหรือเวลาท้องถิ่นมันควรจะผ่าน Unix ไปแล้ว
  • หากคุณต้องการจัดเก็บเวลาที่มนุษย์สามารถอ่านได้ (เช่นบันทึก) ให้พิจารณาจัดเก็บพร้อมกับเวลา Unix ไม่ใช่แทนเวลา Unix
— มิถุนศรีธรรณ์
แหล่งที่มา
1
ไม่เห็นด้วยมากกว่านี้
— Jorge.V
1
สิ่งเดียวที่ฉันจะเพิ่มเข้าไปคือพิจารณาตั้งแต่เริ่มต้นว่าคุณจะต้องพิจารณามิลลิวินาทีที่ใดก็ได้ในระบบของคุณ ในกรณีนี้ให้ใช้การประทับเวลา Unix เวอร์ชันมิลลิวินาที
— jamesjansson
1

ใช้ UTC เสมอ:

ตัวอย่างเช่นฉันมีองค์ประกอบกำหนดการที่ใช้พารามิเตอร์เดียว DATETIME เมื่อฉันเรียกสิ่งนี้โดยใช้คำกริยา GET ฉันใช้รูปแบบต่อไปนี้โดยที่ชื่อพารามิเตอร์ขาเข้าของฉันคือ ScheduleDate

ตัวอย่าง:
https: // localhost / api / getScheduleForDate? scheduleDate = 2003-11-21T01: 11: 11Z

— ไมเคิลเค
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.