Optional parameters in Spring Integration HTTP inbound gateway path

Question

I'm using Spring Integration in order to serve some REST webservice. The url of my service is something like

http://myhost/param1_name/param1_value/param2_name/param2_value

Of course, I don't have only 2 parameters, and I would like to have some of them "optional".

I have found a solution described in the following link http://www.nakov.com/blog/2009/07/15/jax-rs-path-pathparam-and-optional-parameters/

Unfortunately, it doesn't work with Spring Integration. In Spring Integration, whenever I try to use the regexp [^/] to mach a parameter, this doesn't work.

For example, firstName is never matched like this: path="/register/firstName/{firstName:[^/]+}/lastName/"

Any idea, how to achieve optional parameters using Spring Integration ?

Answer 1

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 (eg 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. Eg /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.