如何保持互動的可見性
作為應用協議，
的設計目標是在客戶端和伺服器之間保持對庫、伺服器、**、快取和其他工具的可見性。可見性是
的乙個核心特徵。按
roy fielding
的定義（詳見附錄
a），可見性是
「乙個元件能夠對其他兩個元件之間的互動進行監視或仲裁的能力。
」當協議是可見的時，快取、**、防火牆等元件就可以監視甚至參與其中。
問題描述
您想知道可見性的含義，以及如何保持
請求和響應的可見性。
解決方案
一旦您識別並設計資源，就可以使用
get方法獲取資源的表述，使用
put方法更新資源，使用
delete
方法刪除資源，以及使用
post
方法執行各種不安全和非冪等的操作。可以新增適當的
標頭來描述請求和響應。
問題討論
以下特性完全取決於保持請求和響應的可見性：
快取
快取響應內容，並在資源修改時使快取自動失效。
樂觀併發控制
檢測併發寫入，並在操作過期的表述時防止資源發生變更。
內容協商
在給定資源的多個可用表述中，選擇合適的表述。
安全性和冪等性
確保客戶端可以重複或重試特定的
請求。
當乙個web
服務無法保持可見性時，以上這些功能將無法正常工作。例如，當伺服器對
的使用方式阻礙樂觀併發時，您可能要被迫自己實現應用特定的併發控制機制。
通過以下途徑來實現可見性：
的互動是無狀態的，任何
中介都可以推斷出給定請求和響應的意義，而無須關聯過去或將來的請求和響應。
使用乙個統一介面，包括有
options
，get
，head
，post
，delete
和trace
方法。介面中的每乙個方法操作乙個且僅有乙個資源。每個方法的語法和含義不會因應用程式或資源的不同而發生改變。這就是為什麼
以統一介面而聞名於世了。
使用一種與
mime
類似的信封格式進行表述編碼。這種格式明確區分標頭和內容。標頭是可見的，除了建立、處理訊息的部分，軟體的其他部分都可以不用關心訊息的內容。
考慮乙個更新資源的
請求：
# 請求
# 響應
❶請求行包含
方法、資源路徑和
http 版本
❷請求的表述形式標頭 ❸
請求的表述內容 ❹
響應狀態行包含
版本、狀態碼和狀態訊息 ❺
響應的表述形式標頭 ❻
響應的表述內容
這個例子的請求是乙個
訊息。訊息的第一行描述了客戶端所使用的協議和方
法，接下來的兩行是請求頭。簡單檢視這三行資訊，任何理解
的軟體都可以明白請求的意圖以及如何解析訊息體。響應也是同樣的，響應的第一行表示
版本、狀態碼和狀態訊息，接下來的兩行告訴
軟體如何解釋訊息。 對於
restful web
服務，您的主要目標必定是盡最大可能保持可見性。保持可見性非常簡單，使用
方法時，其語義要與
所規定的語義保持一致，並新增適當的標頭來描述請求和響應。
保持可見性的另一方面是使用適當的狀態碼和狀態訊息，以便**、快取和客戶端可以決定請求的結果。狀態碼是乙個整數，狀態訊息是文字。
正如我們將在
1.2節討論的內容一樣，在某些情況下，您可能需要權衡其他特性，如網路效率、客戶端的便利性以及分離關注點，為此放棄可見性。當您進行這種權衡時，應仔細分析對快取、冪等性、安全性等特性的影響。
本文節選自《
restful web services cookbook
中文版》一書
圖書詳細資訊
:
Volatile如何保證可見性
首先要知道記憶體屏障是什麼，記憶體屏障是乙個cpu指令，記憶體屏障是這樣的指令 1，確保特定操作執行的順序 2，影響一些資料的可見性，編譯器和cpu可以保證輸出結果一樣的前提下對指令進行重排序，使得效能優化，當插入乙個記憶體屏障，相當於告訴cpu和編譯器，先於這個命令的必須先執行，後於這個命令的必須...
繼承的可見性
繼承的可見性 在c 中通過繼承,子類將擁有除父類的 建構函式和析構函式以外的所有的成員.注意這裡的 擁有 和 可見性 是兩個概念.擁有某個成員是指該成員確確實實地存在於該類中,但如果該成員的訪問許可權不允許該成員在繼承的子類中可見 比如private,internal 我們將不能在子類中對他們進行操...
邊的可見性
在 opengl 裡面，邊是具有可見性的，即我們可以讓一條邊顯示或不顯示在螢幕上，有時候我們必須讓一些邊隱藏起來，就像前面說過的利用繪製凸多邊形來繪製凹多邊形的時候就需要隱藏掉一些邊。邊的可見性是利用 gledgeflag 函式來說明的，該函式有乙個引數，且只為 true 或 false 分別表示可...