Bạn đã mô tả hai cách hiệu quả để yêu cầu nhiều ngôn ngữ. Hoặc là nên làm việc tốt. Tôi sẽ chọn tham số yêu cầu ngôn ngữ rõ ràng cho mã của riêng tôi.
TL; DR Backstory
Có một tiêu đề Ngôn ngữ chấp nhận . Lưu ý, Acceptkhông Accepted. Đây là một phần tiêu chuẩn của đàm phán nội dung HTTP. Phản hồi thường đặt lại tiêu đề Ngôn ngữ nội dung .
Accept-Languagelà giá thầu mở, cung cấp một bộ tùy chọn; Content-Languagelà độ phân giải, cho biết ngôn ngữ nào đã được chọn. Hầu hết các Content-Languagecâu trả lời trả về một ngôn ngữ duy nhất, nhưng có một tùy chọn để cung cấp danh sách các ngôn ngữ phản hồi được phân tách bằng dấu phẩy. Thông thường đó sẽ là nội dung hỗn hợp, nhưng không có lý do gì nó không thể báo hiệu nhiều lựa chọn thay thế khác nhau. Nếu bạn muốn khách hàng yêu cầu tất cả các ngôn ngữ có sẵn, đã có tùy chọn yêu cầu ký tự đại diện,* .
Vì vậy, đã có một cơ chế tiêu đề HTTP bạn có thể sử dụng. Tuy nhiên, hãy cẩn thận rằng bạn đang cõng quá trình đàm phán thường trình bày một loạt các tùy chọn có thể và nhận lại một tùy chọn duy nhất. Bạn sẽ chuyển ý nghĩa sang "đây là danh sách các tùy chọn, đưa cho tôi tất cả chúng!" Nếu bạn ổn với điều đó, bạn đã có một giải pháp.
Tuy nhiên, có tranh luận đáng kể về sự phù hợp của việc báo hiệu các tham số API REST trong các tiêu đề HTTP. Nó giống như vào một nhà hàng và thốt ra đơn đặt hàng chi tiết của bạn cho chủ nhà hoặc maître d 'thay vì chờ người phục vụ hoặc nhân viên phục vụ xuất hiện. Nó có thể hoạt động và có thể hoạt động tốt, ví dụ: nếu đơn hàng hướng đến máy chủ liên quan đến đồ uống hoặc món khai vị - những thứ mà chủ nhà có thể nhanh chóng nhìn thấy hoặc nhanh chóng liên lạc với máy chủ của bạn. Nhưng nó cũng có thể được coi là vi phạm giao thức, được xử lý ở cấp độ / lớp sai hoặc trình phát sai.
Một thay thế thứ hai sẽ là một tham số yêu cầu rõ ràng. Bạn đề nghị ?all_languages=true. Điều đó dường như quá cụ thể. Một cái gì đó như lang=en,fr,es(cho phép nhiều ngôn ngữ được liệt kê) hoặc lang=*hoặclang=all (chỉ định mọi ngôn ngữ có sẵn) có vẻ chung chung hơn. Điều này có thể được thể hiện trong URL hoặc cơ thể yêu cầu.
Dù bằng cách nào, phản ứng đa ngôn ngữ của bạn có thể dễ dàng được mã hóa thành tải trọng JSON được trả về:
[ { "lang": "en", "content": "As Gregor Samsa awoke one morning..." },
{ "lang": "de", "content": "Als Gregor Samsa eines Morgens..." },
...
]
Cuối cùng, một trong hai cách tiếp cận này sẽ phù hợp với bạn. Hoặc có thể được xem như là một "thiết kế API RESTful nhất quán, có cấu trúc tốt." Việc xác định tốt hơn chủ yếu dựa vào thái độ của bạn đối với sự phù hợp của việc cõng (và thay đổi một chút ý nghĩa điển hình của) các tiêu đề đàm phán nội dung HTTP.
Sở thích riêng của tôi là không trộn lẫn các tiêu đề và các tham số khác dưới dạng các phần bằng nhau của yêu cầu API. Các rõ ràng langhoặc languagetham số có vẻ sạch hơn đối với tôi. Nhưng kể từ khi HTTP động từ (ví dụ như GET, PUT, POST, PATCH, ...) là một phần của tiêu đề, và cũng rất quan trọng để / trộn lẫn với việc giải thích các yêu cầu, tôi thừa nhận phong bì vs nội dung phân biệt là một chút nhân tạo và mờ. Như với hầu hết các quyết định thiết kế, các chuyên gia chính hãng trả lời khác nhau và YMMV.