Локализация фразы причины в строке состояния ответа API RESTful HTTP - PullRequest
Новая
       14

Локализация фразы причины в строке состояния ответа API RESTful HTTP

1 голос
/ 07 марта 2011

У нас есть RESTful API, предоставляемый через HTTP, который естественным образом использует строку состояния HTTP (код состояния и фразу-причину) для передачи клиенту результата API (http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html).

).

Например, у нас есть следующая строка состояния для ошибки параллелизма:

HTTP / 1.1 409 Ресурс обновлен другим пользователем. Перезагрузите и попробуйте снова.

Недавно выяснилось, что эти сообщения будут представлены конечным пользователям приложения, созданного на основе нашего API, что означает необходимость их локализации. Мне интересно, является ли это приемлемым подходом в таких сценариях, особенно с учетом кодировки этих сообщений, не относящихся к ASCII, или следует, чтобы фраза причины (описание статуса) оставалась только в качестве сообщения низкого уровня и любого содержимого, которое будет 'путь к экрану пользователя должен быть передан в теле ответа? Есть ли что-нибудь, что может укусить нас позже, если мы решим локализовать часть фразы-разума?

В этом случае мы хотели бы использовать тело ответа, чтобы передать новую версию ресурса клиенту API, и добавление дополнительных данных не подходит для этого.

Ответы [ 2 ]

4 голосов
/ 07 марта 2011

Не существует согласованного способа передачи не-ASCII-символов в фразе причины, поэтому я буду очень осторожен, полагаясь на это, если это необходимо для работы вне экспериментальной среды.в тело ответа будет более надежным.

3 голосов
/ 07 марта 2011

Как вы узнаете из RFC:

Код статуса предназначен для использования автоматы и разум-фраза предназначен для человека

Так что стоит попытаться найти баланс между чем-то коротким и конкретным, оставаясь при этом удобным для пользователя. Многие веб-сервисы, которые я видел, имеют узел статуса (xml или json), содержащий код и более удобное для человека сообщение как часть данных ответа.

Одна потенциальная проблема: в одном из наших RESTful API мы настроили фразу причины для помощи в отладке. Мы отслеживали время безотказной работы с Pingdom, который неправильно принимал услугу как доступную, если статус соответствовал тем, которые предложены в RFC - (то есть 200 OK). Указав им, что это неправильно, меня направили в RFC (!), Хотя они в конечном итоге признали, что неправильно его истолковали.

...