REST GET API에 권장되는 날짜 형식

105

다음과 같은 REST GET API에 권장되는 타임 스탬프 형식은 무엇입니까?

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

실제 날짜 형식은 YYYY-MM-DDThh:mm:ssZUTC 시간 과 같은 ISO 8601 형식이어야한다고 생각합니다 .

다음과 같이 하이픈과 콜론없이 ISO 8601 버전을 사용해야합니다.

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

또는 예를 들어 base64 인코딩을 사용하여 ISO 8601 형식을 인코딩해야합니까?

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
감사합니다, 매우 유용한 답변입니다. http://api.example.com/start_date/YYYYMMDDThhmmssZ가독성과 깨끗한 URL에 좋은 ISO 8601 압축 버전 (예 :)을 선택하겠습니다 .
— Lorenzo Polidori 2012 년
7
하지만 JSON 에는 권장되는 날짜 형식이 있으며 ISO 8601입니다. :)
— Radu Potop 2012
@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 형식에서 발생할 수있는 사람의 가독성 문제를 방지하기 위해 정수 시대를 권장합니다. 다른 견해가 있으면 알려주세요.
— Andy 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
자주 연결되고 심하게 토론되는 기사. 문자열이어야하는 경우 정렬 가능한 형식을 선택하는 데 동의하지만 유닉스 타임 스탬프 (기사에서 인정하지도 않음)에는 명시된 모든 이점 등이 있습니다. 프레젠테이션 전까지는 시간대와 일광 절약 (및 정치적 결정) 문제가 존재하지 않습니다.
— kaay
18

RFC6690 - 제약이 편안하고 환경 (코어) 링크 형식은 명시 적으로 그러나에 있어야 어떤 날짜 형식 상태하지 않는 섹션 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
소스
12

입력 / 출력의 모든 datetime 필드는 UNIX / epoch 형식 이어야 합니다. 이렇게하면 API의 여러 측면에서 개발자 간의 혼동을 피할 수 있습니다.

장점 :

  • Epoch 형식에는 시간대가 없습니다.
  • Epoch에는 단일 형식이 있습니다 (Unix 시간은 단일 부호있는 숫자 임).
  • Epoch 시간은 일광 절약 시간에 영향을받지 않습니다.
  • 대부분의 백엔드 프레임 워크와 모든 기본 ios / android API는 epoch 변환을 지원합니다.
  • 현지 시간 변환 부분은 사용자 기기 / 브라우저의 시간대 설정에 따라 애플리케이션 측에서 전적으로 수행 할 수 있습니다.

단점 :

  • 데이터베이스에 UTC 형식으로 저장하기 위해 UTC로 변환하기위한 추가 처리.
  • 입력 / 출력의 가독성.
  • GET URL의 가독성.

노트:

  • 시간대는 프레젠테이션 레이어 문제입니다! 대부분의 코드는 시간대 나 현지 시간을 다루지 않아야하며 Unix 시간을 전달해야합니다.
  • 사람이 읽을 수있는 시간 (예 : 로그)을 저장하려면 Unix 시간 대신 Unix 시간과 함께 저장하는 것이 좋습니다.
— 미툰 스리 다란
소스
1
더 이상 동의 할 수 없습니다.
— Jorge.V
1
여기에 추가 할 유일한 것은 시스템의 어느 곳에서나 밀리 초를 고려해야하는지 처음부터 고려하는 것입니다. 그렇다면 Unix 타임 스탬프의 밀리 초 버전을 사용하십시오.
— jamesjansson
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.