RESTful URL: где я должен указать locale? example.com/en/page против example.com/page ?locale=en

#url #rest #path #locale

#url #отдых #путь #язык

Вопрос:

Я решаю, как организовать URL и поместить в него locale. У меня есть два варианта:

  1. example.com/en/page
  2. example.com/page ?locale=en — Google путь
  3. en.example.com/page — не очень хорошо, потому что я использую поддомены

С одной стороны example.com/en/page выглядит лучше и компактнее, чем example.com/page?locale=en . С другой стороны, у нас есть два URL example.com/en/page -адреса и example.com/ru/page для одного ресурса с двумя представлениями. Конечно, в случае example.com/page?locale=en , если у нас тоже есть два URL-адреса для одного ресурса, но на мой вкус это немного более спокойно.

Какова наилучшая практика? Что вы используете и почему?

Ответ №1:

Локализация является частью согласования содержимого в Restful API.

Так что мой предпочтительный способ, которым я бы сделал это через заголовки. HTTP предлагает стандартный способ определения требуемого языка. Взгляните на заголовок Accept-Language.

Комментарии:

1. ДА. Я знаю о языке принятия. Но в России, например, многие люди используют английский язык, но предпочитают контент на русском. Поэтому, если я буду использовать только Accept-Language, у них не будет возможности изменить язык содержимого (за исключением, конечно, изменения локали браузера). Наиболее распространенным решением является переключатель языков в макете сайта. Итак, я пытаюсь понять, что является лучшим способом организации такого переключателя.

2. Я вижу, значит, ваши api-клиенты являются браузерами (например, через вызовы AJAX)? Тогда я бы выбрал предложенный вами способ настройки URL-адреса (например, ?lang=en), потому что он предлагает вам «необязательную» семантику (с возвратом к заголовку Accept-Language).

3. Браузеры и внешние службы. Спасибо за ваше мнение, я думаю так же.

4. Я не вижу проблемы с использованием Accept-Language . Да, когда ваш браузер отправляет HTTP-запрос для страницы (скорее всего, только для вашего SPA-индекса), он отправит значение, установленное в настройках браузера. Но для всех ваших запросов к API, используя Ajax , вы, конечно, можете указать любое значение, которое вы хотите для этого заголовка — любой приличный фреймворк позволит вам настроить это автоматически. Таким образом, вы все равно можете позволить пользователю выбирать языковой стандарт, например, из выпадающего списка, и всегда отправлять его вместе с каждым последовательным запросом.

Ответ №2:

Из https://www.w3.org/International/questions/qa-accept-lang-locales:

Заголовок HTTP Accept-Language изначально предназначался только для указания языка пользователя. Однако, поскольку многим приложениям необходимо знать языковой стандарт пользователя, обычная практика использует Accept-Language для определения этой информации. Не рекомендуется использовать только заголовок HTTP Accept-Language для определения языка пользователя. Если вы используете исключительно Accept-Language, вы можете приковать пользователя к набору вариантов, которые ему не нравятся.

Мои предпочтения:

  • Запрос
    • используйте параметр запроса
    • возврат к Accept-Language заголовку, если параметр запроса не указан
    • возврат к документированному языку по умолчанию, если Accept-Language заголовок не определен
  • Ответ
    • Установить Content-Language
    • Установите языковой стандарт в полезной нагрузке ответа, например <some-root-tag xml:lang="en-US"> (см. http://www.opentag.com/xfaq_lang.htm )