REST API가 날짜 시간을 적절한 클라이언트 시간대로 변환 할 수 있어야합니까?

10

API를 구현하는 동안 날짜 시간 및 시간대 문제가 발생했습니다.

모든 날짜는 데이터베이스에서 UTC로 정규화됩니다. 현재 비 API 응용 프로그램에서 모든 날짜 시간은 먼저 제시된 사용자 기본 설정을 기반으로 변환됩니다.

이제 API에 대해 동일한 질문이 제기되었습니다. API가 요청 의미에 따라 시간대에 적합한 날짜 시간을 반환 할 수 있어야합니까?

예를 들어 GET /posts?timezone=America/Sao_Paulo?

아니면 API에 액세스하는 클라이언트에서 계속 수행해야합니까?

업데이트 : 그것은 몇 번을 온 이후 : 현재 타임 스탬프 와 시간대가 반환됩니다 (이것은 항상 TZ 오프셋 있지만 +00:00). 형식은 인기있는 8601입니다.2015-10-29T23:00:49+00:00

rest api time

— 표
소스

시간대가 포함 된 타임 스탬프를 반환하면 클라이언트는 필요한 현지 시간으로 쉽게 타임 스탬프를 변환 할 수 있습니다. 어쨌든이 질문은 전혀 REST 관련이없는 것 같습니다. REST의 원칙을 위반하지 않는 여러 가지 방법으로이를 구현할 수 있습니다. 이 매개 변수를 노출하면 더 많은 작업을 수행 할 수 있습니다. 진정으로 RESTful 한 아키텍처에서는 이러한 링크를 어떻게 든 검색 할 수 있어야합니다. 클라이언트 측과 서버 측 모두에서 구현하는 것은 불필요하게 복잡한 일입니다.

— toniedzwiedz

> 클라이언트와 서버 측 모두에서 구현하는 것은 불필요하게 복잡한 일입니다. 입력 주셔서 감사합니다!

— 마크

17

절대 시점을 반환하면 누구나 필요할 때마다 해당 타임 스탬프를 현지화 할 수 있습니다. "절대 타임 스탬프"는 표준 ISO 형식 중 하나 (예 : "2007-04-05T14 : 30Z")로 시간대를 포함하는 UNIX 타임 스탬프 또는 사람이 읽을 수있는 타임 스탬프를 의미합니다. 필요에 따라 클라이언트가 로컬 시간대로 간단하게 변환 할 수 있습니다.

시간대 매개 변수를 승인하고 시간 소인을 해당 시간대로 현지화하려면 괜찮지 만 여전히 절대 시간 소인을 포함해야합니다. 응답의 시간대 (예 : "2007-04-05T16 : 30-02 : 00"). 이 값이 지역화되지 않은 이전 값과 동일하다는 점을 감안할 때이 매개 변수를 제공하는 데 어려움을 겪는 이유는 꽤 의심 스럽다. 타임 스탬프의 정확한 표시 형식은 궁극적으로 클라이언트의 프론트 엔드에 달려 있으므로 어쨌든 값을 사후 처리 할 수 있습니다.

— 속이다
소스

4

"왜 문제를 겪게 되었는가에 의문의 여지가 있습니다." 이 API의 다음 클라이언트 strftime는 첫 번째 클라이언트가 시간대를 지정하는 것이 유용하다는 것과 같은 편리한 이유로 형식 (월 / 일 이름의 로케일)을 지정하도록 요청할 수 있습니다 . 시간대가 유일한 양보 인 경우에도 API 응답을 더 복잡하게 만들었습니다. 더 이상 "매번 같은 형식의 타임 스탬프"가 아니라 "내가 표현하는 방식으로 표현 된 타임 스탬프"

— Steve Jessop

3

정확히, 복잡성. 복잡성은 악하다. 그것은 제품이나 비즈니스에 부가 가치없이 모든 사람이 더 열심히 일하게합니다. 천 종이 베인 죽음.

— Brandon

2

> 당신은 내가 이미 이것을하고 있다는 내 질문을 분명히 한 절대 시점으로 돌아와야합니다. 통찰력 주셔서 감사합니다!

— 마크

4

날짜 시간 값을 사용자의 현지 시간대로 변환하는 로직이 이미있는 경우 API에서 두 가지 가능성을 모두 제공 할 수 있습니다.

클라이언트가와 같은 요청 GET /posts을하면 기본 시간대 (UTC)로 모든 시간을받습니다.
클라이언트가와 같은 요청 GET /posts?timezone=America/Sao_Paul을하면 응답의 모든 시간이 지정된 시간대로 조정됩니다.

그런 다음 시간대로 수행하려는 작업은 클라이언트 구현에 달려 있습니다.

— 바트 반 인겐 스케 나우
소스

2

일반적으로 API에서 UTC를 기대합니다.

그러나 'REST API'가 자바 스크립트 프레임 워크를 사용하는 웹 페이지의 서버 측 부분 인 경우. 실제로 ViewModel을 반환하므로 지역화 된 문자열, 숫자 및 시간이 포함되어야한다고 주장합니다.

— 이완
소스

2

나쁘고 나쁘고 나쁜 생각입니다. 클라이언트가 서버의 응답을 저장 한 다음 사용자가 다른 시간대로 이동하는 상황을 고려하십시오. 이제 당신은이 "기능"이 당신에게 어떤 이점도 제공하지 못하거나 막대한 문제를 일으킬 수있는 상황에 처해 있습니다.

BTW. 몇 개의 시간대와 얼마나 많은 클라이언트를 테스트하려고합니까? 서버가 America / Sao_Paul에 대한 예상 응답을 제공하면 America / Sao_Paulo에 대해 어떤 응답을합니까?

— gnasher729
소스

그건 내 실수 였어 America/Sao_Paulo. 시간대를 식별 할 수없는 경우 어떻게되는지 논의해야합니다. 그것은 분명하지 않거나 TZ 데이터베이스가 오래 되었기 때문에 (후자는 실제 이름은 아닐 것입니다. 그러나 오프셋 값은 아닙니다). 그러나 두 경우 모두 400 BAD_REQUEST응답을 반환합니다 .

— 마크