คุณได้อธิบายวิธีที่มีประสิทธิภาพสองวิธีในการขอหลายภาษา ควรทำงานได้ดี ฉันจะเลือกพารามิเตอร์คำขอภาษาที่ชัดเจนสำหรับรหัสของฉันเอง
TL; DR Backstory
มีเป็นส่วนหัว Accept-ภาษา หมายเหตุไม่Accept Acceptedเป็นส่วนมาตรฐานของการเจรจาต่อรองเนื้อหา HTTP การตอบกลับมักจะตั้งหัวข้อของเนื้อหาภาษากลับ
Accept-Languageเป็นการเสนอราคาเปิดเสนอชุดตัวเลือก; Content-Languageคือความละเอียดซึ่งระบุว่าเลือกภาษาใด Content-Languageคำตอบส่วนใหญ่ส่งคืนภาษาเดียว แต่มีตัวเลือกให้รายการภาษาการตอบกลับที่คั่นด้วยเครื่องหมายจุลภาค โดยทั่วไปแล้วจะเป็นเนื้อหาแบบผสม แต่ไม่มีเหตุผลที่จะไม่สามารถส่งสัญญาณทางเลือกหลาย ๆ *ถ้าคุณอยากให้ลูกค้าที่จะขอภาษาที่มีอยู่ทั้งหมดมีอยู่แล้วเป็นตัวเลือกที่คำขอตัวแทน
ดังนั้นจึงมีกลไกส่วนหัว HTTP ที่คุณสามารถใช้ได้ อย่างไรก็ตามระวังว่าคุณจะต้องดำเนินการเจรจาต่อรองซึ่งมักจะนำเสนอตัวเลือกต่าง ๆ ที่เป็นไปได้และกลับมาเป็นตัวเลือกเดียว คุณจะเปลี่ยนความรู้สึกเป็น "นี่คือรายการตัวเลือกให้ฉันทั้งหมด!" หากคุณไม่เป็นไรคุณก็จะได้ทางออก
อย่างไรก็ตามมีการถกเถียงกันอย่างมากเกี่ยวกับความเหมาะสมของการส่งสัญญาณพารามิเตอร์ REST API ในส่วนหัว HTTP มันเหมือนกับการเข้าไปในร้านอาหารและเบลอคำสั่งซื้อของคุณอย่างละเอียดไปยังโฮสต์หรือผู้ดูแลแทนที่จะรอให้บริกรหรือพนักงานเสิร์ฟปรากฏ มันสามารถทำงานได้และอาจทำงานได้ดีเช่นหากคำสั่งที่โฮสต์โดยตรงเกี่ยวข้องกับเครื่องดื่มหรืออาหารทานเล่น - สิ่งที่โฮสต์สามารถดูได้อย่างรวดเร็วหรือสื่อสารกับเซิร์ฟเวอร์ของคุณอย่างรวดเร็ว แต่มันก็ยังถูกมองว่าเป็นการฝ่าฝืนโปรโตคอลที่อยู่ในระดับ / เลเยอร์ที่ไม่ถูกต้องหรือต่อผู้เล่นที่ผิด
ทางเลือกที่สองจะเป็นพารามิเตอร์คำขอที่ชัดเจน ?all_languages=trueคุณแนะนำ ดูเหมือนจะเฉพาะเจาะจงมากเกินไป บางสิ่งเช่นlang=en,fr,es(อนุญาตหลายภาษาที่มีรายชื่อ) lang=*หรือlang=all(ระบุทุกภาษาที่มี) ดูเหมือนทั่วไปมากขึ้น สิ่งนี้สามารถแสดงได้ใน URL หรือเนื้อความคำขอ
ไม่ว่าจะด้วยวิธีใดการตอบสนองหลายภาษาของคุณสามารถเข้ารหัสลงใน JSON payload ที่ส่งคืนได้อย่างง่ายดาย:
[ { "lang": "en", "content": "As Gregor Samsa awoke one morning..." },
{ "lang": "de", "content": "Als Gregor Samsa eines Morgens..." },
...
]
ในที่สุดวิธีใดวิธีหนึ่งเหล่านี้ควรจะทำงานได้ดีสำหรับคุณ อาจถูกมองว่าเป็น "การออกแบบ RESTful API ที่มีความสอดคล้องและมีโครงสร้างที่ดี" การตัดสินใจว่าส่วนใดจะดีกว่าขึ้นอยู่กับทัศนคติของคุณที่มีต่อความเหมาะสมของการ piggybacking (และเปลี่ยนความรู้สึกทั่วไปของส่วนหัว) การเจรจาต่อรองเนื้อหา HTTP
การตั้งค่าของฉันเองคือไม่ให้ส่วนหัวผสมและพารามิเตอร์อื่น ๆ เป็นส่วนเท่า ๆ กันของคำขอ API พารามิเตอร์langหรือlanguageพารามิเตอร์ชัดเจนกว่าสำหรับฉัน แต่เนื่องจาก HTTP คำกริยา (เช่นGET, PUT, POST, PATCH, ... ) เป็นส่วนหนึ่งของส่วนหัวและยังสำคัญต่อการ / ผสมกับการตีความของการร้องขอผมยอมรับซองเทียบกับเนื้อหาแตกต่างเป็นเทียมบิตและเลือน เช่นเดียวกับการตัดสินใจออกแบบส่วนใหญ่ผู้เชี่ยวชาญของแท้จะตอบคำถามต่างกันและ YMMV