REST: How to pass query parameters


I'm having difficulties trying to figure (if possible) how to  create an URL that also matches query parameters.

I tried:

 <Route Url="/:namespace/test(\?id\=):id" Method="GET" Call="Test"/>
 <Route Url="/:namespace/test?(id)=:id" Method="GET" Call="Test"/>
 <Route Url="/:namespace/test?id=:id" Method="GET" Call="Test"/>


But none of these worked.

Is it possible when using %CSP.REST or am I restricted to using route parameters?

Thank you.


Forget about the "id" parameter name. It's a bad sample: normally id are by definition, able to be hierarchically included in the URI.

Think on id as being something that's not hierarchical, like the sample below:



This would force the URI to be designed in a way that can't be expressed by route paramers, since "fields" doesn't belong to users, as it's really abstract.

So let's consider the URLMap as:

<Route Url="/users/:id(\?fields\=):fields" Method="GET" Call="Test"/>
 <Route Url="/users/:id?(fields)=:fields" Method="GET" Call="Test"/>
 <Route Url="/users/:id?fields=:fields" Method="GET" Call="Test"/>

  • 0
  • 0
  • 787
  • 3
  • 2


Let's say you have called this url:


And you have this route:

<Route Url="/users/:id" Method="GET" Call="Test"/>

Then in your Test method call:

write %request.Get("fields")

it would output list.

Hi Rubens

Fabian wrote a great article about RegExp matching in the Routes here:

However, I don't believe that you can do conditional expressions inside the Route.  I think you would instead have to do this in your Method code (happy to be corrected by someone more clever than I am)



Yeah, I read that a few days ago. But I noticed it doesn't mention how to handle "?".
Hmm, I see... so according to your idea,  I basically have to fetch the parameters by using %request.Get.

Yes, you can get the name/value params from the url by %request.Get("paramname") for example, but using query params at all is against good principles of REST.

I think that the default convention for REST usage has been exploited too much already, to the point that most would prefer to have an extra feature than follow it strictly. Even Google and Facebook do it: though they use REST most of their services, they also allow to pass query parameters.

I think it's due to their performance or readability policies.


By allowing query parameters, you can also prevent another rule break: 

Let's say I need to pass a lot of parameters to FETCH data from a resource. As REST demand, you need to use GET verb to fetch data from the resource if you won't change it.

However if you can't use query parameters, you need to use POST or PUT to provide the payload (that modifies data) and this would break the CRUD rule as well.

This is where I would balance the rule breaks, that is, I can't really disregard breaking a rule that actually prevents me from breaking another that's even more explicit.