WebDriver設計
WebDriver的API被定位為“基于對象的”。接口被明確定義并努力堅持只包含一個角色或者責任，而不是將每一個可能的HTML標記模塊化為單獨的類，只有一個WebElement接口。通過這種方式，開發(fā)人員使用支持自動補全的IDE即可被提示下一步工作。其結果類似于下面的代碼片段（Java語言）：
WebDriver driver = new FirefoxDriver();
driver.<user hits space>
此時，包含13個方法的短列表顯示出來，用戶選擇其中一個：
driver.findElement(<user hits space>)
大多數IDE現(xiàn)在顯示預期參數的類型提示，在這個例子中是“By”。By包含許多預定義的靜態(tài)工廠方法，用戶可以快速地完成剛才的代碼：
driver.findElement(By.id("some_id"));
基于角色的接口
WebDriver廣泛使用了基于角色的接口。例如，有一個JavascriptExecutor接口提供了在當前頁面環(huán)境中執(zhí)行任意Javascript語句塊的功能。WebDriver實例對該接口的成功映射可以提示你利用該方法完成自己的工作。
處理大量的組合
假設X種瀏覽器和Y種語言，我們很容易會掉進X×Y種實現(xiàn)中，將會面臨維護成本的大量攀升。
減少WebDriver支持的編程語言種類是降低成本的途徑之一，但是基于兩種原因不想這樣做。首先，從一種語言切換到另一種時人們會承受認知負荷，因此對用戶來說如果測試框架（WebDriver）能夠允許他們采用在日常開發(fā)中使用的編程語言來編寫測試，那么這是巨大的優(yōu)勢。其次，在單一項目中混合多種語言可能會讓團隊很不方便，而且公司的編碼規(guī)范和需求通常要求技術單一純正性，因此，減少支持語言的種類不是可選項。
減少支持瀏覽器的數量也不是一種選擇——當項目組決定在WebDriver中淘汰對Firefox 2的支持時，遇到了強烈的抗議，而事實上當時，F(xiàn)irefox 2只占了瀏覽器市場份額不到1%。
的選擇是努力使所有瀏覽器對語言的綁定看起來相同：它們應該提供統(tǒng)一的接口，可以輕松地通過各種語言解決。更重要的是，希望語言綁定本身盡可能的易于編寫，這意味著需要盡可能的使它們保持簡潔。在底層driver中放入了盡可能多的邏輯來支持這種設計：放棄放入dirver的每一塊功能都意味著需要通過支持的每一種語言實現(xiàn)，而這代表了大量的工作量。
WebDriver設計中的缺陷
通過這種方式發(fā)布功能的缺陷在于除非有人知道某個特定的接口存在，否則他們可能不會意識到WebDriver支持這種功能，在API的可發(fā)掘性上存在缺憾。當然在WebDriver剛發(fā)布的時候，我們會投入大量時間來指導人們找到合適的接口�，F(xiàn)在我們已經花費大量精力來編寫文檔，隨著API獲得廣泛應用，用戶會越來越容易的找到所需的文檔。
從實現(xiàn)者的觀點來看，緊密綁定瀏覽器也是一種設計缺陷，雖然無法避免。支持新瀏覽器時需要投入巨大的努力，經常需要數次嘗試才能找到正確方法。具體的例子是，Chrome驅動經過了四次完全重寫，IE驅動也有三種關鍵重寫。緊密綁定瀏覽器的優(yōu)點在于它提供了更多控制權。
遠程Webdriver協(xié)議的第二次迭代因此使用了HTTP傳輸機制和UTF-8編碼的JSON作為默認的編碼，使客戶端可以很容易的使用各種有限支持Unicode的語言，因為UTF-8向后兼容ASCII。發(fā)送給服務器的命令使用URL以確定哪個命令被發(fā)送，并編碼在一個數組中的命令的參數。
例如，一個命令WebDriver.get("http://www.example.com")映射到一個到URL的POST請求，編碼了回話ID和以”/”結束，使用像{[}'http://www.example.com'{]}這樣的參數的陣列。返回的結果更有結構性，有一個返回值和錯誤碼的代碼占位。不久到了第三次遠程協(xié)議迭代，使用命名參數字典取代了參數請求數組。這有利于更方便的調試請求，消除了客戶端失誤使用了參數的可能性，使得系統(tǒng)更健壯。當然，決定使用正常的HTTP錯誤碼表示確定的返回值和響應，例如，如果用戶試圖調用一個沒有映射到的URL，或者當我們想表示空響應時，這是種合適的方式。
Webdriver遠程協(xié)議有兩個錯誤處理層次，一個無效的請求和一個失敗的命令。無效的請求的例子是請求一個服務器并不存在的資源，或者可能是資源不理解，（例如發(fā)送一個DELETE命令給用于處理當前頁面的URL的資源）。這種情況下，一個正常的HTTP響應是4XX。對于失敗的命令，錯誤碼設置為500（服務器端錯誤），并且返回的數據包含更詳細的錯誤分解。
當包含數據的響應從服務器發(fā)出后，它是一個JSON對象的格式：
Key 描述
Sessionid 服務器使用的決定何處路由特定會話命令的不透明處理
狀態(tài)值 一個概括命令結果數字狀態(tài)碼，非零值代表命令失敗響應的JSON值
例如：
FirefoxDriver.prototype.getElementAttribute =
function(respond， parameters) {
var element = Utils.getElementAt(parameters.id， respond.session.getDocument());
var attributeName = parameters.name;
respond.value = webdriver.element.getAttribute(element， attributeName);
respond.send();
};
因為可見，我們會在響應中編碼狀態(tài)碼，使用非零值表示發(fā)生了糟糕的事故。首先在IE driver上使用了狀態(tài)碼，而且被用于了線協(xié)議。因為所有的錯誤碼在不同的driver中一致的，在不同的driver中可以使用特殊的語言完成共享錯誤處理的代碼，使客戶端更容易實現(xiàn)。
遠程webdriver服務簡單講是一個Java servlet，扮演多重角色，路由收到的所有的命令給對應的Webdriver實例。諸如此類的事情，一個大二的學生都能完成。Firefox driver也完成了遠程Webdriver協(xié)議，它的架構更加有趣，所以讓我們跟蹤一個從語言綁定的會話到后端一直到返回給用戶的請求。
