Dan Allen wrote:
Thanks for the response Bill. Let's line that up with what we
have today.
* Unique URIs to each "page"
We are going to call these "pretty" or "friendly" URLs and it is
slated
for JSF 2.1. We intentionally want to avoid the word REST here.
"pretty" or "friendly" is nice to have, but not necessary just as long
as each "thing" has a unique, linkable, URI.
* don't overload the meaning of HTTP methods. i.e. don't change
state of server with a GET
JSF 2.0 will have bookmarkable URLs, which are used, for example, to
retrieve a record by ID. In JSF 2.1 we intend to add page actions, which
may change the state of the server with a GET, but those are
discretionary cases to adapt to an action-oriented world (sometimes, it
just has to be done).
Why can't POST be used? Sys admins and caches don't understand an
action-oriented world, but they do know the difference between GET and POST.
REST is about obeying the constraints of HTTP instead of tunneling a new
protocol on top of it. This allows you to leverage existing
infrastructure and well-known tools. RESTFul apps also like to take
advantage of some of the more complex features of HTTP like caching and
content-negotiation.
I don't know whether this fits into JSF or not as I don't know much
about it. To be honest, I'm not sure I want to know, but I'd be happy
to help as I can.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com