2013-11-24 39 views
2

我們有一個單頁面應用程序(AngularJs),它使用REST API與後端進行交互。該應用程序允許每個用戶查看有關用戶所在公司的信息,但不能查看任何其他公司的數據。我們目前的REST API看起來是這樣的:RESTful如何使用子域名作爲資源標識符?

domain.com/companies/123 
domain.com/companies/123/employees 
domain.com/employees/987 

注意:所有ID是GUID的,因此最後的終點沒有公司ID,就僱員ID。

我們最近開始致力於強制要求每個用戶訪問與用戶工作公司有關的信息。這意味着在後端我們需要跟蹤登錄用戶的身份(這是簡單的認證問題),以及確定正在訪問其信息的公司。後者不易從我們的REST API調用中確定,因爲其中一些不包含公司標識,例如上面顯示的最後一個。

我們決定不用在用戶界面中跟蹤公司ID並將它與每個請求一起發送,而是將其放在子域中。因此,假設ACME公司擁有ID = 123我們的API將發生如下改變:

acme.domain.com 
acme.domain.com/employees 
acme.domain.com/employees/987 

這使得識別公司在後端很容易的,需要小的改動休息從我們的單頁的應用程序調用。但是,我擔心的是它打破了我們API的RESTfulness。這也可能引入一些CORS問題,但我現在沒有用例。

我想聽聽你對此的看法,以及你過去如何處理這個問題。

謝謝!

回答

3

在類似的應用程序中,我們確實將'公司id'放入路徑(每個公司特定路徑),而不是子域。

我不會在乎某個術語發燒友是否認爲我的設計是「RESTful 」,但我可以看到使用域的幾個缺點,主要是因爲世界傾向於認爲域標識「服務器」,路徑是如何在該服務器上找到項目。將有一定量的額外的東西,你必須處理與多個域,你會不會與路徑:

  • HTTPS - 你需要一個通配符證書,而不是一個簡單的
  • 的DNS - 你要麼有通配符的DNS條目,要麼你的應用管理現在要涉及DNS管理
  • 你提到的所有CORS的東西 - 可能會或可能不會讓你的特定應用頭痛 - 任何關於安全策略的'相同領域'假設將會受到影響。

當然,如果你想很多公司之間的隔離,有效地你會快樂運行的每個公司的獨立服務器,那麼這不是一個糟糕的設計。我看不出它有多少RESTful,因爲這只是一個觀點問題。

+0

我們決定繼續使用子域方法,並遇到了管理cookie的小問題。只是認爲我會將此添加爲子域方法的另一個潛在問題。 – alecswan

+0

有趣的是,我想我會把'餅乾'放在那個列表中,但顯然我沒有!我有一些輕微的感覺,一些聰明的屁股會馬上出現,並說如果你正確地管理你的cookies不應該是一個真正的問題。我認爲它遵循相同的原則,也就是說系統中的其他位使用域來表達額外的含義,這些含義可能會與你的相沖突。 –

1

使用子域名沒有什麼「不穩定」。 REST中的URI是不透明的,這意味着你並不關心URI是什麼,而只是關於系統中的每一個資源都可以被獨立識別和引用的事實。

另外,在一個RESTful應用程序中,您從不手動編寫URL,而是遍歷在API端點和所有返回的響應中找到的超媒體鏈接。由於您不需要手動編寫URI,因此從REST的角度來看,它們的外觀無關緊要。具有URI如 //domain.com/ABGHTYT12345H 將如下的RESTful作爲 //domain.com/companies/acme/employees/123 或 //domain.com/acme/employees/smith-charles 或 //acme.domain.com/employees/123

所有這些都是同樣RESTful。

但是...我喜歡想到可用的API,當涉及到具有可讀的有意義的URL的可用性對我來說是必須的。還遵循約定是一個好主意。在你的特定情況下,這條路線沒有什麼不安,但在API中找到這種行爲是不尋常的,因此它可能不是最佳實踐。此外,正如有人指出的那樣,這可能複雜化開發

會(不會專門對CORS部分雖然,一個很容易被髮送的HTTP頭的解決),即使我看不到任何東西非REST您的提案,其他地方的約定將違反API上的子域名。

+0

在我的原始文章中包含的RESTful API中,初始入口點是明確的 - 它是acme.com/customers。 在API的子域版本中 - 入口點不明確。它可能類似於admin.acme.com/customers。 缺乏API的明確起點是我擔心它不那麼RESTful。 感謝您分享您的想法。 – alecswan