I have had a discussion with Rossen Stoyanchev on the matter and he found your original approach wrong. Here is his words:
The path is supposed to reflect the hierarchy of REST resources. Concerns such as encoding and content type don't belong there. They're cross-cutting and could apply to any URL. Just imagine a REST API that supports /encoding/utf-8/format/pdf on every URL. In Spring MVC we even support content negotiation by query parameter (e.g. format=pdf), or file extension (.pdf) as first-class mechanisms alternative to using the Accept header (based on ContentNegotiationStrategy). That's common practice and I can't imagine why anyone would think to put such information in path variables.
He does have an example with firstName and optional lastName. I don't think that's a good idea either. First of all names can change even if not often. Also think of all the places where a person can appear in a REST API. Now you'd have to support firstName with optional lastName everywhere. E.g. /person/{firstName}/{lastName}/children/{firstName}/{lastName}.
Seems like both examples are trying to put random data in the URL path that belongs to query parameters or the request body. The path should reflect hierarchy of resources
BTW the referenced article actually says JAX-RS doesn't support optional path variables. He describes it as a hack.
So, would be better if you can move those optinal parts to the request params and have some generic path to map them all. Or... @RequestMapping has params option to allow map the method to the URL, if it contains or not specific params.
