Особо выделяется одна вещь, которая не соответствует REST: использование GET-запроса для выхода из системы.
(из http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods)
Некоторые методы (например, HEAD, GET, OPTIONS и TRACE) определены как безопасные, что означает, что они предназначены только для поиска информации и не должны изменять состояние сервера. Другими словами, они не должны иметь побочных эффектов, за исключением относительно безвредных эффектов, таких как регистрация, кэширование, показ баннерной рекламы или увеличение счетчика. [...]
[... H] andling [GET-запросов] сервером технически никоим образом не ограничен. Следовательно, неосторожное или преднамеренное программирование может привести к нетривиальным изменениям на сервере. Это не рекомендуется, потому что это может вызвать проблемы для веб-кэширования, поисковых систем и других автоматических агентов [...]
Что касается выхода из системы и перенаправления, вы можете получить сообщение на ваш URI выхода из системы и дать ответ 303, перенаправляющий на страницу после выхода из системы.
http://en.wikipedia.org/wiki/Post/Redirect/Get
http://en.wikipedia.org/wiki/HTTP_303
Изменить для решения проблем дизайна URL:
"Как мне спроектировать мои ресурсы?" это важный вопрос для меня; "Как мне создать URL-адреса?" это рассмотрение в двух областях:
URL-адреса, которые будут видеть пользователи, не должны быть слишком уродливыми и значимыми, если это возможно;
если вы хотите, чтобы файлы cookie отправлялись в запросах на какой-либо ресурс, но не на другие, вам нужно структурировать свои пути и пути файлов cookie.
Если JRandomUser
хочет посмотреть его собственный профиль, и вы хотите, чтобы URL был красивее, чем foo.com/user/JRandomUser
или foo.com/user/(JRandom's numeric user id here)
, вы можете создать отдельный URL, чтобы пользователь мог просматривать его собственную информацию:
GET foo.com/profile /*examines cookies to figure out who
* is logged in (SomeUser) and then
* displays the same response as a
* GET to foo.com/users/SomeUser.
*/
Я бы сказал, что невежество в этом вопросе гораздо легче, чем мудрость, но вот несколько соображений относительно дизайна ресурса:
- Потребитель: какие ресурсы предназначены для просмотра непосредственно в браузере, загрузки через XHR или доступа к какому-либо другому виду клиента?
- Доступ / личность: зависит ли ответ от файлов cookie или ссылок?