REST不透明鏈接和應用程序的前端

Question

在REST URI中，客戶端應該是不透明的。 但是，當您爲應用程序構建基於交互式JavaScript的Web客戶端時，您實際上有兩個客戶端！一個用於與服務器進行交互，另一個用於用戶（實際的GUI）。當然，你會希望擁有友好的URI，足以回答「我現在在哪裏？」的問題。

服務器只是用HTML做出響應，這樣人們可以直接點擊鏈接並且不關心結構，這樣更容易。服務器提供URI，服務器接收URI。

桌面客戶端更容易。同樣的工作人員。只是一個按鈕「顯示資源」，用戶不關心URI是什麼。

瀏覽器客戶端很複雜。有地址欄。這導致Web客戶端的低級部分依賴於服務器的URI結構。哪個不是RESTful。

看起來應用程序的前端和後端之間的空間對於REST來說太緊了。

這是否意味着REST不是反應式交互式基於js的瀏覽器客戶端的理想選擇？

Answer 1

我覺得你有點糊塗......

首先，你最初的假設是有缺陷的。 URI不透明並不意味着URI必須是神祕的。這隻意味着客戶端不應該依賴URI語義進行交互。友好的URI不僅被允許，它們被鼓勵的原因與你談論的原因完全相同：開發人員更容易知道發生了什麼。

羅伊菲爾丁made that clear在REST郵件列表年前，但似乎這是不會輕易消失的一個神話：

REST不要求一個URI是不透明的。在我的論文中，唯一發生在詞不透明處的地方是我抱怨餅乾不透明的 。事實上，REST風格的應用程序在所有的 時間，鼓勵使用人類有意義的階層標識符，以便最大限度地簡化原始應用程序預期的信息使用。

其次，你認爲當服務器只是用HTML做出響應時更容易，因此人們可以關注鏈接而不關心結構。那麼，這正是REST應該做的。 REST僅僅是Web本身的架構風格的更正式和抽象的定義。對REST和HATEOAS做一些研究。

最後，要回答你的問題，REST是否是一個很好的選擇，並不取決於客戶端的實現細節。您可以擁有基於js的客戶端，沒有問題，但是需要這樣做並不足以讓您擔心REST的正確性。如果您擁有長期集成，可維護性和演進目標的項目，REST是一個不錯的選擇。如果您需要快速，不會變化很多，或者不會與很多不同的客戶和服務集成，請不要過多關注REST。