Ответ 1
Действительно, JSF как объект, ориентированный на форму, использует структуру POST для того же URL-адреса, что и страница с формой <h:form>
. Вы можете подтвердить это, посмотрев URL <form action>
сгенерированного вывода HTML. Это в терминах веб-разработки, охарактеризованных как обратная передача. Навигация по обратной передаче по умолчанию не вызывает новый запрос к новому URL-адресу, но вместо этого загружает целевую страницу в качестве содержимого ответа. Это действительно сбивает с толку, когда вы просто хотите навигация по страницам.
Как правило, правильный подход к навигации/перенаправлению зависит от бизнес-требований и idempotence (read: "bookmarkability" ) запрос.
-
Если запрос является идемпотентным, просто используйте форму/ссылку GET вместо формы POST (т.е. используйте
<form>
,<h:link>
или<h:button>
вместо<h:form>
и<h:commandXxx>
).
Например, навигация по страницам, форма поиска в Google и т.д. -
Если запрос не является идемпотентным, просто покажите результаты условно в одном представлении (т.е. return
null
илиvoid
и используйте, например,<h:message(s)>
и/илиrendered
).
Например, ввод/редактирование данных, многошаговый мастер, модальный диалог, форма подтверждения и т.д. -
Если запрос не является идемпотентным, но целевая страница является идемпотентной, просто отправьте перенаправление после POST (т.е. верните результат с помощью
?faces-redirect=true
или<redirect/>
).
Например, показывая список всех данных после успешного редактирования, перенаправляйте после входа и т.д.
Обратите внимание, что чистая навигация по страницам обычно является идемпотентной, и именно поэтому многие стартеры JSF терпят неудачу, злоупотребляя командами/кнопками для этого, а затем после этого жалуются, что эти URL не изменяются. Также обратите внимание, что случаи навигации очень редко используются в приложениях реального мира, которые разрабатываются в отношении SEO/UX, и это приводит к тому, что многие учебники JSF терпят неудачу, позволяя читателям поверить иначе.
Также обратите внимание, что использование POST абсолютно не "более безопасно", чем GET, поскольку параметры запроса не отображаются сразу в URL-адресе. Они все еще видны в теле запроса HTTP и все еще манипулируются. Поэтому нет абсолютно никаких оснований предпочитать POST для идемпотентных запросов ради "безопасности". Реальная безопасность заключается в использовании HTTPS вместо HTTP и проверке методов бизнес-обслуживания, если в настоящее время зарегистрированный пользователь может запрашивать объект X или манипулировать объектом X и т.д. Применимая система безопасности предлагает аннотации для этого.
См. также:
- В чем разница между перенаправлением и навигацией/переходом и когда использовать что?
- JSF неявная и явная навигация
- Закладка с помощью функции параметров просмотра
- Что может < f: metadata > , < f: viewParam > и < f: viewAction > для использования?
- Когда следует использовать h: outputLink вместо h: commandLink?
- Создание страниц главной страницы для сущностей, как их связать и какую область bean выбрать
- Сохранять параметры строки запроса запроса GET в форме формы JSF
- Передайте объект между @ViewScoped beans без использования параметров GET