Разрешение пользователю изменять состояние приложения (например, язык) в веб-приложении RESTful - PullRequest
1 голос
/ 15 августа 2011

В настоящее время я переписываю старое веб-приложение и хочу, чтобы оно было RESTful. Одна философия важный , стоящая за приложением RESTful, заключается в том, что каждый запрос к конечной точке должен быть без сохранения состояния .

С приложением я стремлюсь к общей базе кода для API, как для обычного просмотра. Другими словами, я хочу избегать специальных URL, таких как http://api.domain.tld или http://domain.tld/api. Я намерен интерпретировать для этого заголовок HTTP Accept.

Одна проблема, с которой я столкнулся, это параметры запроса, которые пользователь, просматривающий страницу, обычно выбирает только один раз. Хорошим примером для этого является язык. Опять же, я могу использовать заголовок Accept-Language, чтобы выбрать начальный язык. Но что, если пользователь хочет изменить это? Было бы непригодно, если бы пользователю приходилось переключать язык после каждого запроса.

На мой взгляд, это действительно параметр запроса, и его следует передавать как таковой. Например: http://domain.tld/resource?lang=en. Поэтому, как только пользователь переключил язык, мне нужно добавить этот параметр к каждому URL на странице.

В некотором смысле, это делает сессию просмотра с состоянием. Есть ли для этого "лучшие практики"? Как бы вы подошли бы к этому. У меня есть идея сохранить эти «глобальные» параметры в сеансе, но, тем не менее, добавить их в каждый URL. Если только сделать API легко обнаруживаемым.

О sidenote: В настоящее время я создаю веб-страницу, используя Flask , которая предоставляет метод url_for для создания URL-адресов. Я рассматриваю возможность переопределения этого, поэтому каждый сгенерированный URL будет иметь параметр. Но это не специфическая проблема Flask. Это то, что большинство сервисов RESTful должны учитывать, поэтому я не буду отмечать это ни python, ни flask!

1 Ответ

1 голос
/ 15 августа 2011

Передача состояния

REST не требует, чтобы каждый запрос не имел состояния.Требование состоит в том, что серверу не нужно управлять состоянием от имени клиента .По сути, каждый запрос должен иметь достаточное состояние , чтобы сервер мог его обработать.

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

...