여러 언어를 요청하는 두 가지 효과적인 방법을 설명했습니다. 잘 작동합니다. 내 코드에 대한 명시 적 언어 요청 매개 변수를 선택합니다.
TL; DR 배경
가 수락-Language 헤더가 . 참고가 Accept아닙니다 Accepted. HTTP 콘텐츠 협상의 표준 부분입니다. 응답은 일반적으로 Content-Language 헤더를 다시 설정합니다 .
Accept-Language옵션 세트를 제공하는 개시 입찰입니다. Content-Language어떤 언어가 선택되었는지를 나타내는 해결책입니다. 대부분의 Content-Language답변은 단일 언어를 반환하지만 쉼표로 구분 된 응답 언어 목록을 제공하는 옵션이 있습니다. 일반적으로 이는 혼합 된 내용이지만 여러 개의 분리 된 대안을 신호 할 수있는 이유는 없습니다. 클라이언트가 사용 가능한 모든 언어를 요청하도록하려면 이미 와일드 카드 요청 옵션이 *있습니다.
사용할 수있는 HTTP 헤더 메커니즘이 이미 있습니다. 그러나 여러 가지 가능한 옵션을 제시하고 단일 옵션을 다시 얻는 협상 프로세스를 피기 백한다는 점에 유의하십시오. 당신은 감각을 "여기에 옵션 목록이 있습니다. 모든 옵션을 알려주세요!" 괜찮다면 해결책이 있습니다.
그러나 HTTP 헤더에서 REST API 매개 변수를 시그널링하는 적합성에 대해서는 상당한 논쟁이 있습니다. 웨이터 또는 웨이트리스가 나타날 때까지 기다리는 대신 식당에 들어가서 주최자 또는 식당에 주문을 흐리게하는 것과 비슷합니다. 호스트에게 지시 된 주문이 음료 또는 전채와 관련이있는 경우에는 잘 작동 할 수 있으며 호스트가 빠르게 볼 수 있거나 서버와 신속하게 통신 할 수 있습니다. 그러나 잘못된 수준 / 계층 또는 잘못된 플레이어에게 전달 된 프로토콜 위반으로 간주 될 수도 있습니다.
두 번째 대안은 명시 적 요청 매개 변수입니다. 당신은 제안 ?all_languages=true합니다. 지나치게 구체적으로 보입니다. lang=en,fr,es(여러 개의 나열된 언어 허용) lang=*또는 lang=all(사용 가능한 모든 언어 지정 ) 과 같은 것이 더 일반적으로 보입니다. 이것은 URL 또는 요청 본문으로 표현 될 수 있습니다.
어느 쪽이든, 다국어 응답을 반환 된 JSON 페이로드로 쉽게 인코딩 할 수 있습니다.
[ { "lang": "en", "content": "As Gregor Samsa awoke one morning..." },
{ "lang": "de", "content": "Als Gregor Samsa eines Morgens..." },
...
]
결국, 이러한 접근 방식 중 하나가 귀하에게 잘 작동합니다. "일관되고 체계적인 RESTful API 디자인"으로 볼 수 있습니다. 어느 쪽이 더 나은지에 대한 결정은 HTTP 콘텐츠 협상 헤더를 피기 백 (일반적인 의미를 약간 변경)하는 적절한 태도에 주로 의존합니다.
필자가 선호하는 것은 헤더와 다른 매개 변수를 API 요청의 동일한 부분으로 혼합 하지 않는 것 입니다. 명시 적 lang또는 language매개 변수가 더 깨끗해 보입니다. 그러나 이후 HTTP 동사를 (예를 들어 GET, PUT, POST, PATCH, ...)가 헤더의 일부이며,에 / 요청의 해석과 혼합 또한 중요한, 내가 봉투 대 내용의 구분이 비트 인공 및 퍼지이다 인정한다. 대부분의 설계 결정과 마찬가지로, 진정한 전문가와는 다르게 대답합니다.