Take the 2-minute tour ×

We've got an ASP.NET MVC project which has a REST API being consumed by a web front-end using Backbone. One of the pieces of functionality is a free text search, which currently uses a URL like this:


This points to a Search Controller like this (with a route mapped accordingly):

public JsonResult Search(string query, int page, int pageSize)
    // Do search

It works fine for simple queries with single words or nothing with complicated characters (eg test, hello+world), but it seems like some special characters like *, &, etc break this fairly easily, and result in the following error:

A potentially dangerous Request.Path value was detected from the client

As the search query is user-entered via a text box, this needs to be more resilient to dealing with search queries that contain invalid characters.

I've tried encoding the search string using encodeURIComponent, but it doesn't seem to encoding all of the problematic characters.

Is there a recommended method of allowing free text search via a REST API? Any thoughts or advice would be appreciated. Thanks.

share|improve this question

2 Answers 2

up vote 2 down vote accepted

I think its better to put the paging parameters in the query string too, rather than in the resource path. After all they are search dependent and not subresources of the resource you are searching in. Also there is this "/Search/Search/", which seems a bit redundant.

So I think your search URL should be:

share|improve this answer
Yep, this is eventually what I ended up doing. –  Mun Jun 5 '12 at 21:37

Not sure if this is the correct solution, but I ended up breaking the search query out of the core part of the URL and moving it into a querystring. So, the REST call now looks like this:


This still uses the same controller:

public JsonResult Search(string q, int page, int pageSize)
    // Do search

Note: the method parameter for the search query has been renamed from query to q to reflect the name of the querystring parameter.

A search URL now looks like this:


It sounds like using querystring parameters with REST calls isn't as bad a I thought it was, and would be acceptable in this type of scenario, but if there is a better way of doing things, I'd still like to hear it. Thanks.

share|improve this answer

Your Answer


