客戶端UI路由與服務器端路由有何區別

當我使用asp.net web API設計一個restful API時，我必須記住我的客戶端處理代表狀態機的url設計嗎？客戶端UI路由與服務器端路由有何區別

爲了更清楚地說明我也在談論URL中的遏制關係。

例如：

我有一個可以有很多Schooylear實體用戶實體。我有一個Schooylear實體，它可以有多個期間實體。

這會導致三個Web API控制器。 UserController，SchoolyearController，PeriodController。現在我問我自己，我應該像暴露途徑：

api/users/1/schoolyears/2013-2014/periods/2014-01-01

的問題是，現在我應該如何映射的HTTP路線???

像上面一個

其實我也從來沒有見過類似的路線，而路線：

api/users/1 
api/schoolyears/2013-2014 
api/periods/2014-01-01

但與關係包含上述路線將是非常有益的在地址欄，用戶如果看到...

或應該是一個安靜的API不提供代表狀態機的url設計？你看我很困惑客戶端的責任開始或服務器端...

來源

2014-01-13 Elisabeth

當你使用像angularjs這樣的框架優化一個有狀態的JavaScript客戶端，那麼你的組合/嵌套視圖將決定你的url的構造單曲。你不必在服務器上做任何特殊的事情。只要保持你的路線：

api/users/1 
api/schoolyears/2013-2014 
api/periods/2014-01-01

如你所願。這些路由與客戶端狀態無關，這些路由不會將客戶端請求轉發更多。

在客戶端設置好路線與佔位符這是customerId`s

或

orderId`s。當您現在更改組合框中的客戶時，您可以使用新選定的customerId更新您的路線，然後導航到該路線以獲取相應的訂單。

你在客戶端做的僅僅是改變了URL，而不重定向：

jquery: change the URL address without redirecting?

你只創建一個像＃/客戶的哈希後「URL」/ 1 /命令/ 2

如果你不喜歡的hashbang你也可以去HTML5按壓狀態：

http://badassjs.com/post/840846392/location-hash-is-dead-long-live-html5-pushstate

來源

2014-01-13 21:42:10 msfanboy

一個RE STful系統不關心你的URI是什麼樣的。Web框架關心你的URI結構。想要使用你的URI作爲「UI」的一部分是一個有效的關注。
具有多個路徑參數的更長的URI並不是Web API v1中最簡單的事情。通過屬性路由，它應該更容易。

您需要謹慎的唯一事情就是生成層次結構，其中相同的概念資源出現在層次結構中的多個位置。這對於緩存並不是一個好主意。

你不希望在你的情況，

api/users/1/schoolyears/2013-2014/periods/2014-01-01

而且

api/users/1/periods/2014-01-01

來源

2014-01-14 12:33:11

「你不希望在情況下，你有，... 「是的，我想成爲這種情況！當我正確理解msfanboy時，我需要mysite.com/#/users/1/schoolyears/2013-2014/periods/2014-01-01這對服務器路由沒有影響，因爲hashbang是客戶端路由。再次，我需要這樣的網址，用戶如何能夠將鏈接加入書籤並再次快速加載？該鏈接需要整個信息鏈，否則無法裝載2014年1月1日的期間。 – Elisabeth

@Elisa我的假設（也許這是不正確的）是這兩個URL都會返回完全相同的表示。如果是這樣，你不想有兩個返回相同表示的URI。你可以讓一個URI返回一個重定向到另一個。這將允許這兩個URI並不會中斷緩存。 –

@Elisa我還沒有弄清楚URI片段的相關性與你的問題。 –

客戶端UI路由與服務器端路由有何區別

回答

相關問題