命令和查詢責(zé)任分離（CQRS）是由Greg Young提出的一種將系統(tǒng)的讀（查詢）、寫(xiě)（命令）操作分離為兩種獨(dú)立子系統(tǒng)的架構(gòu)模式。命令通常是異步執(zhí)行的，并存儲(chǔ)在一個(gè)事務(wù)型數(shù)據(jù)庫(kù)中，而讀操作則通常是最終一致的，并且數(shù)據(jù)來(lái)自于解正規(guī)化的視圖。

本文在此提出并為讀者展示一種為CQRS系統(tǒng)創(chuàng)建一套R(shí)ESTful API的方式。這種方式結(jié)合了HTTP的語(yǔ)義、REST API基于資源的風(fēng)格，并能夠處理分布式計(jì)算的某些問(wèn)題，例如最終一致性和并發(fā)性。

此外我們還提供了一套原型API，它建立于Greg Young編寫(xiě)的m-r CQRS原型之上，后者也被稱為SimplestPossibleThing。m-r可以認(rèn)為是CQRS原型的事實(shí)標(biāo)準(zhǔn)，它鼓舞了許多團(tuán)隊(duì)采用并創(chuàng)建CQRS系統(tǒng)。雖然這個(gè)m-r原型很簡(jiǎn)單，但它已經(jīng)能夠展示在現(xiàn)實(shí)世界中使用RESTful CQRS系統(tǒng)的某些機(jī)遇和挑戰(zhàn)了。

我們?cè)趯⑾乱徊糠謱忛唌-r的領(lǐng)域模型，隨后對(duì)相關(guān)特性的API設(shè)計(jì)進(jìn)行一些探索。最后，我們將對(duì)一些所做的選擇展開(kāi)討論，并且討論一些RESTful m-r的概念和理論內(nèi)容。

m-r領(lǐng)域

m-r模型是一個(gè)經(jīng)過(guò)簡(jiǎn)化的庫(kù)存管理系統(tǒng)的領(lǐng)域模型，你可以創(chuàng)建新庫(kù)存物品（假設(shè)它是某種類型的產(chǎn)品），重命名或取消激活（即邏輯刪除）它們。被取消激活的物品將不再為用戶所見(jiàn)，而所有活動(dòng)的物品都可以被獲取，并且能夠看到每個(gè)物品的所有細(xì)節(jié)。你也能夠增加或減少這些庫(kù)存物品，指定所加入或減少的物品數(shù)據(jù)。換句話說(shuō)，在建立庫(kù)存量之后，就可以開(kāi)始使用這個(gè)系統(tǒng)了。

用戶將通過(guò)同步的查詢來(lái)查看物品列表或是物品細(xì)節(jié)，對(duì)于物品狀態(tài)的修改將通過(guò)命令來(lái)實(shí)現(xiàn)。在現(xiàn)實(shí)世界中，命令應(yīng)該是異步執(zhí)行的，但由于代碼中使用了內(nèi)存中的事件總線（Event Bus）及事件處理函數(shù)，因此在最終實(shí)現(xiàn)中命令都是同步執(zhí)行的。

m-r模型實(shí)現(xiàn)了CQRS：命令和查詢被分別存儲(chǔ)在不同的地方，并且各自由系統(tǒng)中完全不同的部分進(jìn)行處理。

除了CQRS之外，m-r也使用了事件溯源（Event Sourcing）作為它的持久化機(jī)制。在這種方式中，對(duì)于領(lǐng)域模型的修改會(huì)被捕獲為一系列的事件，這些事件會(huì)按照它們被調(diào)用的順序存儲(chǔ)起來(lái)。為了獲取某個(gè)模型的當(dāng)前狀態(tài)，需要將所有事件按照它們發(fā)生的順序進(jìn)行重播。換句話說(shuō)，模型中實(shí)體的狀態(tài)信息是不會(huì)被持久化的。舉例來(lái)說(shuō)，如果我們創(chuàng)建了一個(gè)庫(kù)存物品，隨后將它重命名兩次，那么我們將會(huì)得到一個(gè)InventoryItemCreated事件和兩個(gè)InventoryItemRenamed事件，這些事件都會(huì)被保存在事件存儲(chǔ)（Event Store）中。

事件是連續(xù)的，并且每個(gè)事件都帶有一個(gè)版本號(hào)，用以在并發(fā)時(shí)進(jìn)行檢查。舉例來(lái)說(shuō)，如果某個(gè)庫(kù)存物品在版本2的基礎(chǔ)上進(jìn)行重命名，但正好有另一個(gè)重命名發(fā)生在同一個(gè)物品上，并使它的當(dāng)前版本變?yōu)?，那么這種情況就會(huì)導(dǎo)致并發(fā)異常。

命令與領(lǐng)域事件通常是一對(duì)一的關(guān)系，當(dāng)調(diào)用了某個(gè)命令之后，領(lǐng)域模型會(huì)發(fā)起并存儲(chǔ)一個(gè)事件。領(lǐng)域事件是事件溯源的基石，它和跨多個(gè)邊界上下文（bounded context）的事件不同，往往粒度更細(xì)，并且只包括所需的最小數(shù)量的信息。因此，它并不是一個(gè)適合于在不同的邊界上下文之間進(jìn)行集成的工具。除了使用一個(gè)進(jìn)程內(nèi)的事件總線之外，m-r還用到了一個(gè)內(nèi)存中的事件存儲(chǔ)。這個(gè)存儲(chǔ)本質(zhì)就是一個(gè)哈希表，它使用模型的id作為鍵，并且持續(xù)跟蹤模型中發(fā)生的任何事件。

如欲了解CQRS和事件溯源的更多信息，你可以閱讀Greg Young的這本迷你書(shū)。

創(chuàng)建一套上層的REST API

如果你傾向于先去感受一下最終的實(shí)現(xiàn)，可以在這里看一下一個(gè)目前（暫時(shí)性）可運(yùn)行的原型。我們鼓勵(lì)你使用fiddler或者瀏覽器自帶的開(kāi)發(fā)工具去檢查一下這個(gè)簡(jiǎn)單的示例中的HTTP請(qǐng)求。在GitHub上可以找到包括這套API和一個(gè)基本的Angular應(yīng)用的源代碼。不過(guò)我們還是要強(qiáng)調(diào)，它的實(shí)現(xiàn)方式和使用的技術(shù)并非關(guān)鍵所在，讀者更應(yīng)該關(guān)注于設(shè)計(jì)方式及HTTP的展現(xiàn)。

公開(kāi)領(lǐng)域的構(gòu)造

對(duì)于這個(gè)API層來(lái)說(shuō)，最重要的責(zé)任是將底層的領(lǐng)域建模為資源，并通過(guò)HTTP語(yǔ)義暴露出來(lái)。在這個(gè)過(guò)程中，API層將創(chuàng)建一個(gè)公共領(lǐng)域，它由資源（以及它們的唯一標(biāo)識(shí)符->URL）以及輸入和輸出的消息所構(gòu)成。底層的領(lǐng)域越簡(jiǎn)單，這個(gè)公開(kāi)領(lǐng)域和底層領(lǐng)域的相似程度就越高。

（單擊圖片以放大）

在這個(gè)例子中，我們創(chuàng)建的公開(kāi)領(lǐng)域與底層的領(lǐng)域還是比較相似的，但即使是這種簡(jiǎn)單的領(lǐng)域，我們也不能夠直接將底層的領(lǐng)域暴露出去：這可能造成領(lǐng)域的內(nèi)部實(shí)現(xiàn)被泄漏出去，而且領(lǐng)域內(nèi)部也不一定包含API層所需的全部屬性。比方說(shuō)，所有的內(nèi)部命令都會(huì)用一個(gè)整數(shù)來(lái)表示并發(fā)時(shí)所需的版本號(hào)，而在公開(kāi)領(lǐng)域中則用字符串表示這個(gè)屬性。我們稍后將會(huì)使用這個(gè)屬性作為ETag，而根據(jù)HTTP規(guī)格要求，ETag必須是不透明的。

簡(jiǎn)單來(lái)說(shuō)，我們所創(chuàng)建的公開(kāi)領(lǐng)域表現(xiàn)了內(nèi)部的領(lǐng)域類，但又不完全相同。這種公開(kāi)領(lǐng)域通常被稱為一個(gè)視圖模型（Vide Model）。這個(gè)術(shù)語(yǔ)并不太準(zhǔn)確，因?yàn)檫@種表達(dá)方式感覺(jué)上對(duì)公開(kāi)領(lǐng)域有些排斥，將它視為一種“啞”模型，因此我們傾向于使用一個(gè)新術(shù)語(yǔ)“輸出模型”（output model）。它將被應(yīng)用到輸入和輸出消息中（命令和輸出模型）。

資源

我們很自然地想到應(yīng)該有一個(gè)InventoryItem資源，因此我們將領(lǐng)域中的這個(gè)單根實(shí)體暴露為一個(gè)單獨(dú)的資源，可以用/api/InventoryItem方便地進(jìn)行表示。每個(gè)庫(kù)存物品將用/api/InventoryItem/{id}進(jìn)行表示，m-r使用了全局唯一標(biāo)識(shí)符（GUID）作為Id。

使用這個(gè)單獨(dú)的根對(duì)象就可以完整的表現(xiàn)我們的領(lǐng)域了。還有一種方式是使用/api/InventoryItem/{id}/Stock這個(gè)資源作為添加和刪除庫(kù)存量（即簽入或移除物品）的方法。從本質(zhì)上說(shuō)它們沒(méi)有什么高下之分，無(wú)非是哪種方式能夠更好地表現(xiàn)資源而已。由于第一種方式更加簡(jiǎn)便，因此我們就使用這種方式。

（單擊圖片以放大）

查詢

我們需要兩個(gè)查詢：GetInventoryItems和GetInventoryItemDetails。這里我們將通過(guò)兩個(gè)GET方法/api/InventoryItem和/api/InventoryItem/{id}暴露出這兩個(gè)查詢功能。

GetInventoryItems方法能夠獲取僅包含了物品名稱和Id的一個(gè)列表，它會(huì)根據(jù)ACCEPT頭決定返回JSON或是XML（ASP.NET Web API能夠支持這一功能）。如果某個(gè)資源適合于緩存，那么所有的GET請(qǐng)求都有可能返回緩存數(shù)據(jù)。GetInventoryItems返回InventoryItemListDataCollection作為輸出消息。雖然可以通過(guò)數(shù)據(jù)內(nèi)容的哈希生成ETag，不過(guò)這里我們選擇將列表中每一項(xiàng)的Id和名稱進(jìn)行哈希后得到的結(jié)果作為ETag返回給客戶端（例如瀏覽器）。客戶端可以選擇將資源緩存起來(lái)，并針對(duì)ETag使用If-Non-Match進(jìn)行條件請(qǐng)求。我們選擇將資源的max-age設(shè)為0，因此客戶端的GET會(huì)始終使用條件請(qǐng)求，不過(guò)也可以選擇設(shè)置一個(gè)人為的過(guò)期時(shí)間。

GET /api/InventoryItem HTTP/1.1 Accept:application/json, text/plain, */* Accept-Encoding:gzip,deflate,sdch If-None-Match:"LdHipfxR7BsfBI3hwqt2BLsno8ic98KmrIA1y67Nnw4="

返回結(jié)果

HTTP/1.1 304 Not Modified ETag: "LdHipfxR7BsfBI3hwqt2BLsno8ic98KmrIA1y67Nnw4="

GetInventoryItemDetails方法會(huì)返回某個(gè)庫(kù)存物品的細(xì)節(jié)，包括Id，Name和CurrentCount屬性，最后一項(xiàng)屬性記錄了當(dāng)前的庫(kù)存數(shù)量。雖然內(nèi)部領(lǐng)域的讀取模型（read model）包含了版本號(hào)，但如果將某個(gè)數(shù)值類型的版本號(hào)直接作為ETag會(huì)產(chǎn)生安全性問(wèn)題，因?yàn)榭蛻舳丝梢暂p易地猜出下一個(gè)數(shù)值。因此，我們選擇了使用高級(jí)加密標(biāo)準(zhǔn)（AES）對(duì)版本號(hào)進(jìn)行加密后，作為InventoryItemDetails方法的ETag輸出。

為每個(gè)操作都重新實(shí)現(xiàn)ETag對(duì)于API層來(lái)說(shuō)有些負(fù)擔(dān)過(guò)重，因此我們定義了一個(gè)IConcurrencyAware接口：

public interface IConcurrencyAware { string ConcurrencyVersion { get; set; } }

每個(gè)支持ETag的輸出模型都要實(shí)現(xiàn)這個(gè)接口，當(dāng)API層看到某個(gè)輸出模型支持這個(gè)接口時(shí)，就會(huì)讀取版本號(hào)并設(shè)置ETag值。另一方面，當(dāng)API層對(duì)條件式GET請(qǐng)求進(jìn)行響應(yīng)時(shí)，會(huì)將生成的ETag與客戶端在If-None-Match頭中傳入的值進(jìn)行比較。所有這些操作都可以通過(guò)一個(gè)單獨(dú)的全局filter實(shí)現(xiàn)：ConcurrencyAwareFilter。

需要注意的是，添加、刪除或者重命名某個(gè)庫(kù)存物品時(shí)應(yīng)該使物品列表的緩存失效。請(qǐng)看下面的例子（條件式GET請(qǐng)求的邏輯是在瀏覽器端完成的，不需要特別編寫(xiě)代碼實(shí)現(xiàn)）：

GET /api/InventoryItem HTTP/1.1 If-None-Match:"CWtdfNImBWZDyaPj4UjiQr/OrCDIpmjVhwp8Zjy+Ok0="

返回結(jié)果是一個(gè)狀態(tài)碼為200的完整響應(yīng)，并且包含了一個(gè)新的ETag值：

HTTP/1.1 200 OK Cache-Control:max-age=0, private Content-Length:68 ETag:"0O/961NRFDiIwvl66T1057MG4jjLaxDBZaZHD9EGeks=" Content-Type:application/json; charset=utf-8; domain- model=InventoryItemListDataCollection; version=1.0.0.0; format=application%2fjson; schema=application%2fjson; is-text=true ...

請(qǐng)注意Content-Type頭包含了額外的參數(shù)，這是對(duì)于“媒體類型的五種級(jí)別”（或者簡(jiǎn)稱5LMT）概念的一種實(shí)現(xiàn)，這種方式不是將所有信息都塞到一個(gè)單獨(dú)的令牌（token）中，而是使用不同的參數(shù)來(lái)表達(dá)對(duì)用戶有用的不同級(jí)別的數(shù)據(jù)，能夠表達(dá)不同級(jí)別的有用信息。下文會(huì)對(duì)這個(gè)主題做進(jìn)一步的討論。

命令

查詢通常會(huì)映射到GET方法，而命令則需要映射到POST、PUT、DELETE和PATCH方法。將HTTP謂詞映射到CRUD操作是一種流行的觀念，但在真實(shí)世界中很少能夠?qū)⒅^詞和數(shù)據(jù)庫(kù)操作一一對(duì)應(yīng)。實(shí)際上，REST API并不在對(duì)持久化存儲(chǔ)之上的一個(gè)簡(jiǎn)單封裝，相反，它是指引用戶去了解業(yè)務(wù)領(lǐng)域、操作與工作流的一扇門(mén)。因此它必須能夠不依賴于特定的謂詞去表達(dá)某個(gè)維度的意圖。

一種常見(jiàn)的方式是使用遠(yuǎn)程過(guò)程調(diào)用（RPC）風(fēng)格的資源，例如/api/InventoryItem/{id}/rename。雖然它看上去確實(shí)去除了對(duì)某種謂詞的依賴，但它違反了REST面向資源的表現(xiàn)能力。我們需要記住，資源是一個(gè)名詞，HTTP謂詞則表示動(dòng)詞和動(dòng)作，而自描述的消息（REST的宗旨之一）則是表達(dá)其它維度信息和意圖的手段。實(shí)際上，在HTTP消息中所包含的命令就應(yīng)該足以描述任何人為的操作了。但是，完全依賴于請(qǐng)求體中的消息也有它自己的問(wèn)題，因?yàn)檎?qǐng)求體通常是作為流傳遞的，要在辯認(rèn)出它的具體操作之前獲取整個(gè)請(qǐng)求體有時(shí)是不可能做到的，而且這也不是一種明智的做法。這里，我們將展示一種基于5LMT中的第4級(jí)別（即領(lǐng)域模型）處理請(qǐng)求的方式，命令的類型將包含在Content-Type頭中的某個(gè)參數(shù)內(nèi)。

PUT /api/InventoryItem/4454c398-2fbb-4215-b986-fb7b54b62ac5 HTTP/1.1 Accept:application/json, text/plain, */* Accept-Encoding:gzip,deflate,sdch Content-Type:application/json;domain-model=RenameInventoryItemCommand

這樣就能夠?qū)⒄?qǐng)求正確地輸送給服務(wù)端相應(yīng)的處理方法了。那這種方式是否將過(guò)多的信息泄露給客戶端了呢？并非如此。輸入輸出消息的schema（以及名稱）是公開(kāi)領(lǐng)域的一部分，客戶端必須能夠完整地訪問(wèn)到它，因此它們依賴于schema也是在我們所預(yù)期的。

至于客戶端的實(shí)現(xiàn)只用了最少量的代碼，這里使用了一個(gè)AngularJS的裝飾（decorator）封裝了$http服務(wù)，它能夠讀取這個(gè)原型的返回內(nèi)容，并且能夠在Content-Type頭中加入額外的參數(shù)信息。只要保持JavaScript構(gòu)造函數(shù)的名稱不變就沒(méi)有問(wèn)題。

我們已經(jīng)解決了辨認(rèn)當(dāng)前正被調(diào)用的方法的問(wèn)題，接下來(lái)需要將命令按照語(yǔ)義映射到相應(yīng)的HTTP謂詞。在將命令映射到謂詞時(shí)，選擇正確謂詞的關(guān)鍵不僅僅在于語(yǔ)義，同樣要考慮冪等性（至于謂詞的安全性則無(wú)需顧忌，因?yàn)槿魏我粋€(gè)命令謂詞都是不安全的）。PUT、PATCH和DELETE是冪等的，而POST則不是冪等的（多次調(diào)用一個(gè)冪等的謂詞的結(jié)果與僅調(diào)用一次是相同的）。

CreateInventoryItemCommand

從CRUD范式的角度來(lái)說(shuō)，CreateInventoryItemCommand很自然地適用于POST方法。（這里只顯示重要的頭信息）

POST /api/InventoryItem HTTP/1.1 Content-Type:application/json;domain-model=CreateInventoryItemCommand {"name": "CQRS Book"}

返回的響應(yīng)如下:

HTTP/1.1 202 Accepted Location: http://localhost/SimpleCQRS.Api/api/InventoryItem/ 109712b9-c3d5-4948-9947-b07382f9c8d9

該操作將在location頭信息中返回這個(gè)將被創(chuàng)建的庫(kù)存物品（因?yàn)樗胁僮鞫际钱惒綀?zhí)行的）的URL地址。

DeactivateInventoryItemCommand

如同前文所述，取消激活庫(kù)存物品就代表一次邏輯刪除。此外，刪除操作是冪等的，因?yàn)槎啻蝿h除一個(gè)庫(kù)存物品的效果和一次刪除是一樣的。因此我們將使用DELETE選項(xiàng)作為取消激活某個(gè)物品的方式（該方法帶有一個(gè)空的方法體）。

DELETE /api/InventoryItem/f2b75f21-001a-4eed-b8f3-35bf5e4e9b0d HTTP/1.1 Content-Type:application/json;domain-model=DeactivateInventoryItemCommand {}

返回的響應(yīng)如下:

HTTP/1.1 202 Accepted

雖然也可以在方法體中傳遞id，但在URL中已經(jīng)提供了id信息。DeactivateInventoryItemCommand構(gòu)造函數(shù)的唯一職責(zé)是正確地設(shè)置domain-model這個(gè)參數(shù)。

RenameInventoryItemCommand

RenameInventoryItemCommand比起其它命令來(lái)說(shuō)更有趣一點(diǎn)。首先，重命名一個(gè)庫(kù)存物品也就是進(jìn)行修改，因此使用PUT謂詞是最合適的。另一方面，如果你正在重命名某個(gè)物品時(shí)，你的同事也在嘗試將其重命名為另一個(gè)名字的話會(huì)怎樣呢？這就是一個(gè)并發(fā)問(wèn)題。HTTP通過(guò)If-Unmodified-Since和If-Match提供了對(duì)資源進(jìn)行并發(fā)修改時(shí)的保護(hù)機(jī)制。因?yàn)槲覀兪褂昧薊Tag，因此就相應(yīng)地設(shè)置If-Match：

PUT /api/InventoryItem/f2b75f21-001a-4eed-b8f3-35bf5e4e9b0d HTTP/1.1 Content-Type:application/json;domain-model=RenameInventoryItemCommand If-Match:"DL1IsUoH709K+N5TXFzlQeQI5arO8r/U0SzXcRhuXLc=" {"newName": "CQRS Book 1"}

AngularJs的controller會(huì)傳遞ETag值，并傳入模型中，之后在條件式PUT請(qǐng)求時(shí)進(jìn)行使用。如你所見(jiàn)，ETag的值僅僅是對(duì)領(lǐng)域模型中版本號(hào)的一種表現(xiàn)，但我們對(duì)其進(jìn)行加密以滿足HTTP規(guī)格的需要。服務(wù)端獲取到這個(gè)值之后進(jìn)行解密并還原成版本號(hào)的數(shù)值。如果版本號(hào)不匹配，領(lǐng)域模型就會(huì)拋出一個(gè)ConcurrencyException異常，在API層的ConcurrencyExceptionFilterAttribute類捕獲到這個(gè)異常之后，會(huì)以HTTP語(yǔ)義的方式表現(xiàn)該異常。

HTTP/1.1 412 Precondition Failed

這個(gè)例子很好地說(shuō)明了HTTP的并發(fā)如何與CQRS的并發(fā)檢查機(jī)制相結(jié)合。

CheckInItemsToInventoryCommand和RemoveItemsFromInventoryCommand

這兩個(gè)命令就更加有趣了。我們將往庫(kù)存中加入或刪除一些物品。從某方面來(lái)說(shuō)，這種操作是對(duì)庫(kù)存物品的數(shù)量進(jìn)行更新，因此可以將其實(shí)現(xiàn)為一個(gè)PUT（也許PATCH更合適）方法。但因?yàn)檫@兩個(gè)命令并非冪等（比如說(shuō)，調(diào)用CheckInItemsToInventoryCommand兩次應(yīng)該添加兩次庫(kù)存），因此最適合的謂詞實(shí)際上是POST。

客戶端將在Content-Type頭信息中的參數(shù)中設(shè)置領(lǐng)域模型的名稱，如同我們之前所見(jiàn)的一樣。

POST /api/InventoryItem/f2b75f21-001a-4eed-b8f3-35bf5e4e9b0d HTTP/1.1 Content-Type:application/json;domain-model=CheckInItemsToInventoryCommand {"count": "230"}

返回的響應(yīng)是一樣的：

HTTP/1.1 202 Accepted

HTTP的其它方面

實(shí)現(xiàn)HTTP的一些其它方面也會(huì)帶來(lái)一些好處，HEAD也是一個(gè)重要的謂詞，它的響應(yīng)結(jié)果和GET方法一樣，但返回的響應(yīng)體中不包括任何內(nèi)容。我們?yōu)樗蠫ET資源都實(shí)現(xiàn)了HEAD謂詞，例如：

HEAD /api/InventoryItem HTTP/1.1 Accept:application/json, text/plain, */* Accept-Encoding:gzip,deflate,sdch

將返回

HTTP/1.1 200 OK ETag: "LdHipfxR7BsfBI3hwqt2BLsno8ic98KmrIA1y67Nnw4="

具體在實(shí)現(xiàn)中會(huì)將HEAD請(qǐng)求轉(zhuǎn)向給GET方法的處理函數(shù)，而框架本身會(huì)在最后負(fù)責(zé)移除返回的內(nèi)容。這一系列實(shí)現(xiàn)都是自動(dòng)觸發(fā)的，因此在響應(yīng)中可以正確地獲得ETag。

另一個(gè)需要實(shí)現(xiàn)的重要謂詞是OPTIONS，這個(gè)謂詞可以用以生成API文檔，不過(guò)我們這里只是簡(jiǎn)單的返回該資源支持的所有謂詞：

OPTIONS /api/InventoryItem/f2b75f21-001a-4eed-b8f3-35bf5e4e9b0d HTTP/1.1

它將返回如下內(nèi)容：

HTTP/1.1 200 OK Allow: GET,POST,OPTIONS,HEAD,DELETE,PUT Content-Length: 46 Content-Type: application/json; charset=utf-8; domain-model=String%5b%5d; version=4.0.0.0; format=application%2fjson; schema=application%2fjson; is-text=true ["GET","POST","OPTIONS","HEAD","DELETE","PUT"]

請(qǐng)注意，響應(yīng)中的Allow頭對(duì)于OPTIONS請(qǐng)求來(lái)說(shuō)是必須的。不過(guò)HTTP規(guī)格本身并沒(méi)有指定OPTIONS響應(yīng)體中具體寫(xiě)法，因此我們就將允許的謂詞作為一個(gè)字符串?dāng)?shù)組返回（注意，在domain-model參數(shù)中的String[]是經(jīng)過(guò)UrlEncoded方法編碼的結(jié)果）。可以利用這個(gè)謂詞生成符合各種schema和語(yǔ)言需求的API文檔。

除了這些方法之外的任何調(diào)用都會(huì)返回一個(gè)方法未找到（method not found）或者405狀態(tài)碼，ASP.NET Web API自身已經(jīng)實(shí)現(xiàn)了這一功能：

PUT /api/InventoryItem HTTP/1.1 {}

它將返回：

HTTP/1.1 405 Method Not Allowed Allow: POST,GET,HEAD,OPTIONS {"message":"Http Method not supported"}

討論

這一部分將詳細(xì)敘述某些理論概念，以及我們的決定中一些比較困難，或者可能引起爭(zhēng)議的部分。

可選的并發(fā)檢查

在m-r最初的實(shí)現(xiàn)中，所有命令（除了CreateInventoryItemCommand，它已經(jīng)隱式地包含了值為0的版本號(hào)）都包含一個(gè)整數(shù)型的CurrentVersion字段。而這個(gè)版本中將它們修改為可選的（即C#中的可空類型）。

在一方面，服務(wù)端應(yīng)該負(fù)責(zé)保證自身狀態(tài)的完整性。因此它不能、也不應(yīng)該依賴于客戶端所提供的版本號(hào)。并發(fā)檢查是作為一個(gè)特性提供給客戶端的，而不是服務(wù)端用以保證模型完整性的機(jī)制。如果客戶端關(guān)心并發(fā)行為，那它就可以選擇性地發(fā)送版本號(hào)，這已經(jīng)通過(guò)在ETag中的加密信息提供給它們了。要記住的是，并發(fā)檢查與服務(wù)端的事件版本號(hào)是不同的概念，后者是服務(wù)端的內(nèi)部實(shí)現(xiàn)機(jī)制。

另一方面，對(duì)于某些操作來(lái)說(shuō)，并發(fā)檢查是沒(méi)有意義的。舉例來(lái)說(shuō)，如果兩個(gè)客戶端在同一時(shí)間（調(diào)用CheckInItemsToInventoryCommand方法）添加了20個(gè)庫(kù)存物品，并且它們都具有版本號(hào)n，那么其中有一個(gè)命令就會(huì)失敗，但這種失敗是不必要的，因?yàn)槲覀兇_實(shí)需要添加40個(gè)物品。這種問(wèn)題在高訪問(wèn)量的情況下會(huì)被放大。想象一下，如果大量的用戶涌入亞馬遜網(wǎng)站去購(gòu)買哈利波特的最新一期，在多數(shù)情況下他們都會(huì)遇到并發(fā)問(wèn)題。

在HTTP中執(zhí)行PUT（和PATCH）操作時(shí)會(huì)認(rèn)為并發(fā)是一個(gè)可選的檢查，這一點(diǎn)并非偶然。雖然并發(fā)檢查可以異步執(zhí)行，但我們需要盡力保證它必須同步執(zhí)行，因此當(dāng)我們返回狀態(tài)碼202（已接受）時(shí)，就代表服務(wù)端已經(jīng)確認(rèn)了沒(méi)有并發(fā)沖突情況的產(chǎn)生。

媒體類型的五種級(jí)別（5LMT）和創(chuàng)建新的媒體類型

在社區(qū)里常見(jiàn)的一種做法是創(chuàng)建新的媒體類型，通常稱為打造新的媒體類型。舉例來(lái)說(shuō)：

Content-Type:application/vnd.InventoryItemListDataCollection.1.0.0.0+json;

這種使用非正規(guī)的方式表示某個(gè)媒體類型的子類型已經(jīng)成為了一種通用的實(shí)踐（已經(jīng)實(shí)際上成為一種約定了），它將子系統(tǒng)分解為一些特定的、或者是正式的元素，并通過(guò)+號(hào)連接在一起。已經(jīng)有些經(jīng)過(guò)注冊(cè)的媒體類型使用了這種約定，例如application/rss+xml和application/atom+xml。這兩個(gè)示例處于媒體類型級(jí)別中的第3級(jí)別（或者叫做schema級(jí)別），而application/xml則處于第2級(jí)別（format級(jí)別）。某種意義上說(shuō)，application/atom+xml就是一種application/xml類型，它們使用相同的format，而前者還指明了會(huì)使用ATOM schema。

雖然這一約定會(huì)在未來(lái)版本的HTTP規(guī)格中得到認(rèn)可，但它并未解決媒體類型不斷增長(zhǎng)的問(wèn)題。首先，使用任何未注冊(cè)的媒體類型都是HTTP規(guī)格所不提倡的，使用以上類型的Content-Type值也是一樣。實(shí)際上，如果我們需要在所有API中為五個(gè)不同媒體級(jí)別的任意組合都注冊(cè)一種媒體類型，那互聯(lián)網(wǎng)號(hào)碼分配局（IANA）恐怕需要發(fā)動(dòng)一大批人去專門(mén)從事這個(gè)規(guī)模巨大的任務(wù)了。另一方面，許多客戶端系統(tǒng)使用基于dictionary的媒體類型去處理這種請(qǐng)求，它們將不能夠應(yīng)付新創(chuàng)建的媒體類型。

因此使用5LMT能夠允許現(xiàn)有的客戶端繼續(xù)按照之前的方式正常工作，而更先進(jìn)的客戶端則可以利用更高級(jí)別的信息，它們都是作為獨(dú)立的實(shí)體提供的。

通過(guò)一個(gè)公開(kāi)的領(lǐng)域保護(hù)內(nèi)部領(lǐng)域是關(guān)鍵所在

將服務(wù)端的內(nèi)部實(shí)現(xiàn)進(jìn)行抽象對(duì)客戶端來(lái)說(shuō)是非常重要的。如同之前所述，為較小的領(lǐng)域所創(chuàng)建的公開(kāi)領(lǐng)域和內(nèi)部領(lǐng)域會(huì)比較相似，但即使是在m-r這個(gè)示例中，我們也不能夠?qū)?nèi)部領(lǐng)域直接暴露出來(lái)，而必須創(chuàng)建一個(gè)獨(dú)立的模型，它表現(xiàn)了客戶端能夠接收和交互的信息。

我們還應(yīng)該將公開(kāi)領(lǐng)域文檔化，并展現(xiàn)給客戶端。這一方面的進(jìn)展值得關(guān)注，因?yàn)橐呀?jīng)有各種不同的方法和實(shí)踐開(kāi)始露出水面了（從WADL到Swagger、RAML和RestDown等等）。

結(jié)論

不僅通過(guò)一套R(shí)EST API暴露CQRS是可能的，而且HTTP語(yǔ)義的豐富性也使得我們能夠在它的基礎(chǔ)上編寫(xiě)一套流暢而有效的API。整個(gè)流程包括創(chuàng)建一個(gè)由命令和查詢（輸入輸出消息）組成的公開(kāi)領(lǐng)域，以及能夠處理并發(fā)和緩存的各種資源。此外，我們還需要將內(nèi)部領(lǐng)域的查詢和命令映射為HTTP謂詞，并且使用狀態(tài)碼以表現(xiàn)狀態(tài)轉(zhuǎn)換和異常。使用5LMT將有助于創(chuàng)建完全RESTful，而不是遠(yuǎn)程過(guò)程調(diào)用風(fēng)格的資源。所有這些都可以通過(guò)一個(gè)很小但可以運(yùn)行的原型應(yīng)用進(jìn)行展現(xiàn)，該原型是通過(guò)ASP.NET Web API和AngularJS實(shí)現(xiàn)的。

關(guān)于作者

Ali Kheyrollahi 是一位解決方案架構(gòu)師、作者、博主、開(kāi)源軟件的作者和貢獻(xiàn)者，目前任職于倫敦的一家大型電子商務(wù)企業(yè)。他對(duì)HTTP、Web API、REST、DDD和概念模型抱有極大的熱情。而在處理實(shí)際的業(yè)務(wù)問(wèn)題上又堅(jiān)持實(shí)用性。他在這一行已有12年以上的經(jīng)驗(yàn)，并在多個(gè)優(yōu)秀企業(yè)工作過(guò)。他對(duì)于計(jì)算機(jī)視覺(jué)和機(jī)器學(xué)習(xí)領(lǐng)域有著深厚的興趣，并且已經(jīng)發(fā)布了多篇論文。在之前，他曾是一名醫(yī)師，并作為一名非專科醫(yī)生工作了5年。可以在這里找到他的博客，此外他在twitter上也非常活躍，可以通過(guò)@aliostad關(guān)注他。

查看原文地址：Exposing CQRS Through a RESTful API

轉(zhuǎn)載于:https://www.cnblogs.com/shanyou/p/3614780.html

總結(jié)

以上是生活随笔為你收集整理的通过一组RESTful API暴露CQRS系统功能的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。