3

While passing parameters to web API controllers, Is there any rule on whether to use Route data like http://domain/api/employees/1 or to use query string like http://domain/api/employees?id=1 Is it totally opinion based or Is there any guideline on this? does one has any advantage over the other one? I found many questions on how to implement Route data or query string, but I don't know which one should I use when both would do the job.

Iman
  • 717
  • 15
  • 32
  • 1
    Well, down voting with no explanation is kind. – Iman Mar 22 '17 at 03:07
  • 1
    This is an opinion based question. That's why you're being downvoted. – It's a trap Mar 22 '17 at 05:17
  • 1
    That's my exactly what I wanted to know that is it just the preference or there is reasoning or any guideline behind it. Thanks for letting me know. – Iman Mar 23 '17 at 00:54
  • 1
    I prefer route data. But there is nothing much that differs between the 2. It completely depends on your preference. Most arguments are given against query strings also hold for route data like easily manipulated, not good for sending critical data etc. One thing that you need to keep in mind before using query strings is to use parameterized SQL queries. Route data can return 404 status code if anything is not found, but in case of QS, you have to take care in your code – It's a trap Mar 23 '17 at 13:20

2 Answers2

2

Query strings are nice if you have many parameters that are optional. Unlike the default behavior or routing, this is useful if you have parameters that can exist without any preceding parameters. An example of this might be a search feature with many fields.

/q=test%20query&city=some%20city&state=some%20state&occupation=programmer
/q=foo%20bar&occupation=dancer&state=CA

Unlike the default behavior of routing, query string parameters can be supplied in any order and in any combination.

Routing makes for more SEO-friendly URLs. But with the built-in routing, "optional" parameters mean only that the right-most parameter is optional.

/search/foo%20bar/CA/dancer
/search/foo%20bar/CA
/search/foo%20bar

So, you wouldn't be able to do:

/search/foo%20bar/dancer

because it would put the value "dancer" into the route value with the "state" route key.

You can extend routing to make optional parameters that can be supplied in any order, but it is more involved to set up.

/search/query/occupation/dancer/foo%20bar/state/CA/
/search/state/CA/query/foo%20bar
/search/query/foo%20bar/occupation/dancer

Do note that there is one major difference between the two. Query string parameters are not handled by routing (by default, anyway). The reason why they make it to the action method is because they are supplied by value providers. You can control whether query string or route values take precedence (for the entire application) by changing the order of value provider factories.

Community
  • 1
  • 1
NightOwl888
  • 55,572
  • 24
  • 139
  • 212
1

It really just depends on how you want your URLs to look. Query Strings require a little less set-up and work well if you don't really care about how nice a URL looks, and Route Data is really nice to create pretty and intuitive URLs.

If possible, it's probably a better idea to stick to Route Data, but there are many instances where you need to pass in more data than Route Data can fit in while still retaining that nice intuitive quality. It all really comes down to context.

In your employee example, it would be possible to use Route Data and still retain that nice-looking quality, and I personally think it would be more intuitive and better-looking to do so, but in the end it's your call.

Hope this helps.

Lucas Niewohner
  • 327
  • 3
  • 11