API REST có thể chuyển đổi datetime thành múi giờ của máy khách phù hợp không?

10

Trong khi triển khai API của chúng tôi, vấn đề về thời gian và thời gian đã xuất hiện.

Tất cả các ngày được chuẩn hóa thành UTC trong cơ sở dữ liệu. Hiện tại, trong ứng dụng không phải API, tất cả các thời gian được chuyển đổi dựa trên tùy chọn của người dùng trước khi trình bày.

Bây giờ, cùng một câu hỏi được đặt ra cho API: API có thể trả về thời gian thích hợp cho múi giờ dựa trên ngữ nghĩa yêu cầu không?

Ví dụ GET /posts?timezone=America/Sao_Paulo?

Hoặc nó vẫn nên được thực hiện trên bất kỳ ứng dụng khách nào đang truy cập API?

Cập nhật: kể từ khi nó xuất hiện một vài lần: hiện tại dấu thời gian có múi giờ được trả về (mặc dù nó luôn luôn bù TZ +00:00). Định dạng phổ biến là 8601:2015-10-29T23:00:49+00:00

rest api time

— dấu
nguồn

Nếu bạn trả về dấu thời gian có chứa múi giờ, khách hàng có thể dễ dàng chuyển đổi nó thành bất kỳ thời gian địa phương nào cần thiết. Dù sao, câu hỏi này dường như không liên quan đến REST. Có nhiều cách bạn có thể thực hiện điều này mà không vi phạm các nguyên tắc của REST. Xin lưu ý rằng việc phơi bày thông số này có nghĩa là nhiều công việc hơn cho bạn. Trong một kiến trúc RESTful thực sự, bạn sẽ cần phải làm cho các liên kết này có thể được khám phá bằng cách nào đó. Nó tấn công tôi như một điều phức tạp không cần thiết để thực hiện cả ở phía máy khách và máy chủ.

— toniedzwiedz

> Nó gây ấn tượng với tôi như là điều phức tạp không cần thiết để thực hiện cả ở phía máy khách và máy chủ. Cảm ơn các đầu vào!

— đánh dấu

17

Bạn nên trả lại một điểm tuyệt đối trong thời gian, sau đó bất cứ ai cũng có thể bản địa hóa dấu thời gian đó khi cần thiết. Theo "dấu thời gian tuyệt đối" Tôi có nghĩa là dấu thời gian UNIX hoặc dấu thời gian có thể đọc được của con người bao gồm múi giờ ở một trong các định dạng ISO được tiêu chuẩn hóa, ví dụ: "2007-04-05T14: 30Z". Điều này có thể được chuyển đổi thành một múi giờ địa phương bởi khách hàng khi cần thiết.

Nếu bạn muốn chấp nhận tham số múi giờ và bản địa hóa dấu thời gian đến múi giờ đó thì tốt, nhưng bạn vẫn nên sử dụng dấu thời gian tuyệt đối. múi giờ trong phản hồi của bạn, ví dụ: "2007-04-05T16: 30-02: 00". Cho rằng giá trị này giống hệt với giá trị không được bản địa hóa trước đó, thật đáng nghi ngờ tại sao bạn gặp phải rắc rối khi cung cấp tham số này. Định dạng hiển thị chính xác của dấu thời gian cuối cùng tùy thuộc vào giao diện của máy khách, do đó có thể sẽ xử lý hậu kỳ giá trị.

— lừa dối
nguồn

4

"Thật đáng nghi ngờ tại sao bạn lại gặp rắc rối" - nếu không có gì khác, đó là phần cuối của cái nêm. Ứng dụng khách tiếp theo của API này có thể yêu cầu bạn cho phép họ chỉ strftimeđịnh định dạng (cộng với ngôn ngữ, cho tên tháng / ngày) vì cùng lý do thuận tiện mà khách hàng đầu tiên thấy hữu ích khi chỉ định múi giờ. Ngay cả với múi giờ là sự nhượng bộ duy nhất, bạn đã khiến phản hồi API của mình trở nên phức tạp hơn: nó không còn chỉ là "dấu thời gian ở cùng định dạng mỗi lần", đó là "dấu thời gian được thể hiện theo cách tôi được yêu cầu thể hiện"

— Steve Jessop

3

Chính xác, phức tạp. Phức tạp là xấu xa. Nó làm cho mọi người làm việc chăm chỉ hơn mà không có bất kỳ giá trị gia tăng nào cho sản phẩm hoặc doanh nghiệp. Chết bởi một ngàn vết cắt giấy.

— Brandon

2

> Bạn nên trả lại một điểm tuyệt đối trong thời gian tôi làm rõ câu hỏi của tôi rằng tôi đã làm điều này rồi. Cảm ơn sự sáng suốt của bạn!

— đánh dấu

4

Nếu bạn đã có logic để chuyển đổi giá trị datetime thành múi giờ cục bộ của người dùng, bạn có thể cung cấp cả hai khả năng trong API của mình.

Nếu một khách hàng thực hiện một yêu cầu như thế GET /posts, thì họ sẽ nhận được tất cả các lần trong múi giờ mặc định (UTC).
Nếu khách hàng đưa ra yêu cầu như thế GET /posts?timezone=America/Sao_Paul, thì tất cả thời gian trong phản hồi sẽ được điều chỉnh theo múi giờ đã chỉ định.

Sau đó, tùy thuộc vào việc khách hàng thực hiện những gì họ muốn làm với múi giờ.

— Bart van Ingen Schenau
nguồn

2

Thông thường bạn sẽ mong đợi UTC từ một API.

Tuy nhiên, nếu 'API REST' của bạn chỉ là phần phía máy chủ của trang web sử dụng khung javascript. Tôi sẽ lập luận rằng trên thực tế bạn đang trả về một ViewModel và do đó, nó sẽ chứa các chuỗi, số và thời gian được bản địa hóa.

— Ewan
nguồn

2

Đó là một ý tưởng tồi, xấu, xấu. Xem xét một tình huống nơi khách hàng lưu trữ phản hồi từ máy chủ và sau đó người dùng đi đến một múi giờ khác. Bây giờ bạn có một tình huống mà "tính năng" này sẽ cung cấp cho bạn không có lợi thế nào, hoặc tạo ra rắc rối lớn.

BTW. Trong bao nhiêu múi giờ và bao nhiêu khách hàng bạn sẽ kiểm tra điều này? Nếu máy chủ đưa ra câu trả lời dự kiến cho America / Sao_Paul, nó sẽ trả lời gì cho America / Sao_Paulo?

— gnasher729
nguồn

Đó là một lỗi về phía tôi, tôi đã sửa nó thành America/Sao_Paulo. Tôi đoán sẽ thảo luận về những gì xảy ra nếu múi giờ không thể được xác định; hoặc vì nó hoàn toàn sai hoặc cơ sở dữ liệu TZ đã lỗi thời (tôi thấy cái sau không có khả năng cho tên thực tế [nhưng không phải như vậy đối với các giá trị offset). Tuy nhiên, trong cả hai trường hợp, tôi có thể sẽ trả 400 BAD_REQUESTlời.

— đánh dấu