REST服務，UI和服務分離

Question

我正在嘗試了解RESTful服務。 在我正在觀看的本教程中，講師指出以下內容：

REST服務使UI和服務之間的定義變得非常明確。

• 通常，作者在這里暗示什么？
• 用戶界面中使用的服務與用戶界面的其余部分相比很容易發現？
• UI的其余部分是CSS，HTML，還是存儲在本地應用程序中的某些數據？
• UI和服務之間為什么需要明確區分？

您是否知道現有的示例，我可以看一下以更好地從視覺上理解？

Answer 1

如果沒有嵌入上下文的話，就不可能確切地解釋較大摘錄中的單個句子的含義。 但是我還是去。 我懷疑涉及炒作的因素-無法保證Restful API的設計要比非Restful API更好，因此，實際上無法保證它將更好地實現UI邏輯和業務邏輯之間的分離，都希望看到。

但是，Rest的文檔中心主義，對無狀態的關注以及對統一API的使用確實有助於在UI（Web應用程序或移動應用程序）和服務器之間創建干凈的層。

其他形式的面向服務的體系結構，例如RMI或SOAP，往往更側重於提供一種訪問遠程API的方式，就好像它是本地的一樣-本質上掩蓋了網絡負載正在發生的事實。 結果通常是非常細粒度但功能強大的API，該API需要嵌入客戶端應用程序中的復雜邏輯（ 業務邏輯）才能正確使用。 這些協議可能非常閑談，並且網絡效率低下，因為很少關注於通過網絡傳輸的數據。

以文檔為中心的Restful API傾向於將UI設計器推向編輯這些文檔的方向-將UI集中在表示上，並將邏輯留給用戶或后端服務。

Rest的統一接口有助於使API專注於處理文檔-每種資源的訪問方式都相同，幾乎沒有余地添加可以由客戶端以某種方式“解釋”的自定義響應代碼。 出於這個原因，HTTP是一個構建Restful API的好協議-主要動詞是GET，PUT，POST和DELETE。

類似地，Rest的無狀態性促使UI着重於其擁有的數據及其應如何處理，而不是向用戶提供任何類型的中間轉換或緩存層。 除了要向用戶提供的文檔外，UI所提供的信息也不多-漂亮而又簡單。

我猜，您問題的真正核心是“為什么要這樣”？ 答案是，它使事情變得簡單靈活。 表示邏輯（例如，用戶關心的語言，時區或數字格式）不應與業務邏輯（用戶過去購買了多少個“ foo”小部件，他們是否真的想要一個“ bar”小部件）混合使用，因為很多購買“ foo”小部件的人也想要“ bar”小部件）。 這兩種類型的事物具有非常不同的更改原因，並且不同類型的人擅長使用基礎代碼。