Запрос REST API с языком и регионом

Я разрабатываю REST API, и мне нужно реализовать метод, которому нужны язык и страна для получения результата в правильном формате, поскольку результат содержит числа и даты.

Я использовал заголовок HTTP Accept-Language, чтобы получить язык. Спецификации определяют заголовок как спецификатор языка, но теперь я не уверен, правильно ли использовать этот заголовок для получения страны. Например, я хочу разрешить результат на испанском языке, но с числами в английском формате (с запятыми вместо точек).

es-US приемлемое значение для заголовка Accept-Language?

Я думал, что могу разработать новый настраиваемый заголовок, например X-Country, для моего REST API.

Есть предположения? Спасибо.


person Filipo Red    schedule 22.06.2018    source источник
comment
Что вы имеете в виду? (Но с числами в английском формате (с запятыми вместо точек)   -  person Alex Lemesios    schedule 22.06.2018
comment
Номер формата зависит от региона. Например, испанское представление 4.294.967.295000 против US-English 4294967295.00 (docs.oracle.com/cd/E19455-01/806-0169/overview-9/index.html)   -  person Filipo Red    schedule 22.06.2018
comment
Что ж, я должен был сказать запятыми вместо точки   -  person Filipo Red    schedule 22.06.2018
comment
Очень благодарен за отзыв на мой ответ.   -  person cassiomolin    schedule 04.07.2018


Ответы (3)


Есть хорошие документы о том, как локализовать ваши API < / а>. Есть даже ответ о переполнении стека.

В основном это связано с согласованием содержимого и Accept- Заголовок языка. Если вам нужно управлять валютой отдельно, общий консенсус, похоже, сохраняется в полезной нагрузке, а не в заголовках, но если вы собираетесь делать заголовки, я бы сделал X-Accept-Currency (поведение аналогично другим заголовкам HTTP Accept, но с ISO 4217 коды валют) в запросе и X-Content-Currency в ответе.

ОБНОВЛЕНИЕ: все изменилось - если вы собираетесь отправить свой заголовок для стандартизации, вам не следует добавлять к нему префикс X.

person lscoughlin    schedule 22.06.2018

Я думал, что могу разработать новый настраиваемый заголовок, например X-Country, для моего REST API.

Я бы избегал настраиваемых заголовков, если один из стандартных заголовков HTTP соответствует вашим потребностям.

es-US приемлемое значение для заголовка Accept-Language?

Да, es-US (испанский / США) является допустимым языковым стандартом (см. Примечания ниже), и это подходящее значение для инструментов _ 5_:

5.3.5. Accept-Language

Поле заголовка Accept-Language может использоваться пользовательскими агентами для указания набора естественных языков, которые предпочтительны в ответе. Языковые теги определены в разделе 3.1.3.1. [...]

Соответствующие части раздела 3.1.3.1 цитируются ниже:

3.1.3.1. Языковые теги

Языковой тег, как определено в RFC 5646, определяет естественный язык, на котором говорят, пишут или иным образом передаются людьми для передачи информации другим людям. Компьютерные языки явно исключены. [...]

Языковой тег - это последовательность из одного или нескольких вложенных тегов без учета регистра, каждый из которых разделен знаком дефиса (-, %x2D). В большинстве случаев языковой тег состоит из вложенного тега основного языка, который идентифицирует широкое семейство родственных языков (например, en = английский), за которым необязательно следует ряд вложенных тегов, которые уточняют или сужают диапазон этого языка (например, en-CA = разнообразие английского языка, распространенного в Канаде). В языковом теге нельзя использовать пробелы. Примеры тегов включают:

fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN

Дополнительную информацию см. В RFC 5646.


Примечание 1. Комбинации языков и кодов территорий, которые можно считать действительными (в том смысле, что данное население данной территории может читать и писать заданный язык и достаточно удобный для использования на компьютерах) можно найти здесь.

Примечание 2. Не знаю, какой язык программирования вы используете, но здесь список языков, доступных в Java.

person cassiomolin    schedule 22.06.2018

Есть предположения? Спасибо.

Я бы порекомендовал начать с ресурса для каждого (языка, страны), который вы поддерживаете, а затем беспокоиться о том, хотите ли вы иметь единственный ресурс, который выполняет согласование содержания.

Простым шаблоном для ресурса, использующего согласование содержимого, было бы использование Content-Location, чтобы указать на конкретный ресурс для согласованной пары язык / страна.

См. Также ответ Тома Кристи от 2012 г., особенно ссылку на Комментарий Филдинга в 2006 г.

person VoiceOfUnreason    schedule 22.06.2018