An interestingdiscussion is taking place on how one would produce a URL space for a blog style archive using Servlets + JSP. I'll describe the approach Alfresco has taken, which although does not directly complement Servlets + JSP, it is built upon Servlets. Alfresco after all, is a Java implemented application.
'How to produce the URL space' was just one question we considered whilst designing Alfresco RESTful services. Our world is slightly constrained. First, we aren't concerned with supporting any service; we want to allow our community to develop content management oriented RESTful services - the URL space problem is the same, but the implementation behind the URL space is focused. Second, we don't want our community to know Java. We want to offer Alfresco to a wide audience, and whilst they can interact with any client environment, we don't want to constrain those with no Java experience to our rigid view of server resources (with associated URL space & implementation) and rigid view of granularity / transactions. Third, we're not building another fully-fledged UI framework. The focus is on data allowing the exposure and management of content residing within the Alfresco Repository via RESTful (or not) services, although, that hasn't stopped the building of HTMLUI with it.
We decided to take a declarative (XML & URI Template) + server-side scripting (Javascript & Freemarker) approach, building upon scripting technologies already available in Alfresco. This essentially allows the mapping of arbitrary Resources (URIs) to any Alfresco content & services. Resources are introduced without the need for a compile or deploy step with a minimum of XML plumbing (convention over configuration where possible - annotations not available here). Alfresco itself may be used to manage the development of such declarations and scripts. I say Resources, but of course, any form of URL may be constructed meaning RPC style services can still be built; the framework does not interfere.
We chose URI Templates for expressing the URL space for two reasons. First, it's powerful enough for most scenarios (time will tell if we have to introduce a regex style mapping) whilst understandable by all, and second, it allows for smarter client binding in the future where URI Template Parameters are given universal meaning. Simple helpers are available for Resource implementors to retrieve useful parts of the request URI based on the Template.
At this point it's best if I just point you to some examples (folder, search feeds...) built with the framework, and the full URI reference for yet more examples.
Given this framework, the next question for us is how to expose all the built-in Alfresco Repository entities & services as resources providing a supported out-of-the-box starting point API. We'll probably wait to see if anything happens in the standards space (with an eye on ATOM/APP too), but in the mean-time, the Alfresco community will gain experience from developing their own RESTful (or not) content management services.
