雖然參數傳遞到網絡API控制器， http://domain/api/employees/1 或使用查詢字符串像 http://domain/api/employees?id=1 是它完全基於選項上是否有是否使用路由數據，如任何規則或是否有任何指引對此有何看法？一個人比另一個人有什麼優勢嗎？ 我發現了很多關於如何實現路由數據或查詢字符串的問題，但我不知道在兩者都能完成這項工作時應該使用哪一個。何時使用路由數據以及何時在ASP.NET Web API中使用查詢字符串？
如果您有許多可選的參數，查詢字符串很不錯。與默認行爲或路由不同，如果您的參數不存在任何前面的參數，則此參數非常有用。這方面的一個例子可能是許多領域的搜索功能。
/q=test%20query&city=some%20city&state=some%20state&occupation=programmer
/q=foo%20bar&occupation=dancer&state=CA
與路由的默認行爲不同，查詢字符串參數可以以任意順序和任意組合提供。
路由使更多的搜索引擎優化友好的網址。但通過內置路由，「可選」參數僅表示最右邊的參數是可選的。
/search/foo%20bar/CA/dancer
/search/foo%20bar/CA
/search/foo%20bar
所以，你不會是能夠做到：
/search/foo%20bar/dancer
，因爲它會把值「舞者」到路徑值與「國家」路線的關鍵。
您可以擴展路由以製作可以按任意順序提供的可選參數，但它是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
請注意兩者之間有一個主要區別。查詢字符串參數不由路由處理（無論如何，默認情況下）。他們之所以採用行動方法是因爲他們是由value providers提供的。您可以通過更改值提供程序工廠的順序來控制查詢字符串或路由值是否優先（針對整個應用程序）。
好的答案，第一段完美地總結了它。 –
這實際上只取決於你希望你的網址看起來如何。查詢字符串需要稍微少一點的設置，並且如果您不關心URL的外觀有多好，並且Route Data非常適合創建漂亮，直觀的URL，
如果可能的話，堅持路線數據可能是一個更好的主意，但有很多情況下您需要傳遞比Route Data更多的數據，同時仍然保持良好的直觀質量。這一切都歸結於上下文。
在您的員工示例中，可以使用路線數據，並保留好看的質量，我個人認爲這樣做會更直觀，更好看，但最終它是您的呼叫。
希望這會有所幫助。
那麼，沒有解釋下投票是仁慈的。 – Iman
這是一個基於意見的問題。這就是爲什麼你被低估了。 –
這正是我想知道的，這只是偏好，還是有推理或任何背後的指導原則。謝謝你讓我知道。 – Iman