What if your URLs were not an afterthought in your app but the main character from the very first line of code. What if links shaped your content model instead of getting patched at the end with regex and a bag of filters. If your brain nodded there is a good chance you will like how Apache Sling treats resource resolution. Do we really need more controller glue or do we just need to map a clean URL to a content resource and let the right script render it. That is the idea that keeps pulling me back to Sling and why URLs in Sling feel like a feature not a footnote.
In Sling the URL is the starting point.
Sling turns a request path into a Resource that lives in a JCR. From there type hints on the resource pick the script. No servlet mapping xml. No giant front controller. The parts of the URL matter. Path points to the resource. Selectors are extra hints like widget or print. The extension suggests the format like html json txt. And the suffix carries an extra resource path if you want to reference something else. This is clean for SEO and clean for code. You keep your content under /content or whatever tree makes sense and you let the URL describe the view. The mental model is simple. Resolve resource then resolve script then render.
Plain words for a simple flow.
Scripts live alongside the component that knows how to render. The resource has a sling:resourceType, say site/components/product. Sling will try to find a script for that type that matches the request. If you hit /content/site/en/products/widget.print.html Sling looks for a script that supports the type and the selectors and the extension. In this world JSP and ESP are common picks. HTL is not in the mix yet. The best part is how this keeps your URLs flat while your content stays structured. URLs stop leaking storage details and still carry useful intent for caching and for users.
// inside a Sling servlet or script
Resource res = request.getResource();
ValueMap vm = res.adaptTo(ValueMap.class);
SlingHttpServletRequest req = request;
RequestPathInfo info = req.getRequestPathInfo();
String path = res.getPath(); // /content/site/en/products
String selectors = info.getSelectorString(); // widget.print
String ext = info.getExtension(); // html
String suffix = info.getSuffix(); // maybe /sku/123Selectors are like light switches you add to a URL. Flip on widget to add chrome. Add print for a bare template. Put json for a raw view. You avoid query strings for things that are part of the template choice. CDNs and proxies like that since the cache key is clear. Search engines like it because the link tells a story. The extension is not a file type from your disk. It is just a hint for the response. That keeps your content portable inside the JCR without leaking storage details.
Readable and still precise.
The other trick I love is Sling Mappings. You can keep all content under /content and still serve it from the root without a servlet filter that rewrites everything. Create mapping nodes under /etc/map and let Sling do the rewrite both ways. That means author links stay short in the browser and still resolve back to the right resource inside the repo. You can also set up 301s for old sections if you are migrating a site. Move a tree in the JCR and keep the link juice with a tiny mapping. This cuts down on brittle code and keeps SEO friendly URLs intact while your structure evolves behind the scenes.
# JCR nodes for /etc/map
/etc/map
http
localhost.4502
sling:match = localhost.4502/(.*)
sling:internalRedirect = /$1
short-root
sling:match = localhost.4502/(en|de)/(.*)
sling:internalRedirect = /content/site/$1/$2
legacy-products
sling:match = localhost.4502/store/(.*)
sling:redirect = https://localhost:4502/en/products/$1 // 301You can inspect the resolver in the Felix console and watch how a path goes from link to resource to script. I run quick checks with curl and look at response headers and the selected script in logs. This is also what powers Adobe CQ5 which sits on Sling and Felix. With Adobe picking up PhoneGap this week the web stack story keeps getting more interesting. Sling fits nicely when you want content first sites where every URL is a contract. Build content types in the repo. Attach scripts that match selectors and extensions. Let the resolver tie it all together. Less glue. Fewer surprises.
# quick sanity checks
curl -I http://localhost:4502/en/products.widget.html
curl -I http://localhost:4502/en/products.print.json
curl -L http://localhost:4502/store/old-skuTreat the URL as a contract and Sling will do the heavy lifting.