星巴克REST案例分析

如何獵取〔GET〕一杯咖啡REST我們已習(xí)慣于在大型中間件平臺(tái)〔CORBA、WebJ2EE的平臺(tái)〕之上構(gòu)建分布Web運(yùn)行的協(xié)議和文檔格式視為一種應(yīng)-Web在WebGET/connected-Web-basedintegration〔暫定名稱〕里的一些想法。引言Web好的集成由什么構(gòu)成”的觀念。集成〔integration〕并不是一種夾在系統(tǒng)之間的專業(yè)活動(dòng)；與此相反，現(xiàn)在，集成是成功方案里的不行缺少的一局部。然而，仍有很多人誤會(huì)并低估Web在企業(yè)計(jì)算中的作用。即便是那些精通Web的人士，也常常要花費(fèi)很大力氣才能懂得，WebXMLoverRPCWeb的用處；它實(shí)際上是一個(gè)強(qiáng)健的集成平臺(tái)。平臺(tái)，它能夠?qū)ζ髽I(yè)系統(tǒng)做很“酷”的事。另外，工作流是企業(yè)軟件最具代表性的特征。為什么要工作流？〔至少在計(jì)算方面〕。工作流把一項(xiàng)工作〔work〕劃分為多個(gè)離散的步驟〔steps〕以及觸發(fā)步驟轉(zhuǎn)移的大事〔events〕。工作流所實(shí)現(xiàn)的整個(gè)業(yè)務(wù)流程常?？缭郊僭O(shè)干企業(yè)信息系統(tǒng)，這給工作流帶來很多集成問題。星巴克：統(tǒng)一標(biāo)準(zhǔn)的咖啡需要統(tǒng)一標(biāo)準(zhǔn)的集成的交互，以實(shí)現(xiàn)更大的業(yè)務(wù)力量。要恰如其份地介紹工作流，就免不了表達(dá)一大堆跟領(lǐng)域相關(guān)的技術(shù)細(xì)節(jié)，而這不是本文的主旨，因此，我們選擇了GregorHohpe的星巴克工作流這個(gè)比較好理解的例子來舉例說明基于WebGregor成一個(gè)解耦合的〔decoupled〕盈利生產(chǎn)線的：上面作上記號(hào)說明你點(diǎn)的是什么，然后把這個(gè)杯子放到隊(duì)列里去。這里的隊(duì)列指的是在咖啡忙不過來的時(shí)候，收銀員仍舊可以為顧客點(diǎn)單。他們可以在繁忙時(shí)段安排多個(gè)咖啡師，就像競(jìng)爭(zhēng)消費(fèi)者模式〔CompetingConsumer〕里那樣?！盙regorEAI〔如面對(duì)消息的中間件〕Web源〔支持統(tǒng)一接口的可尋址實(shí)體〕Web具有跟傳統(tǒng)EAI工具一樣的牢靠性，以及何以不僅僅是懇求/響應(yīng)協(xié)議之上的XML消息傳遞！首先，我們很內(nèi)疚擅自設(shè)想了星巴克的工作流程，由于我們的目的并不是準(zhǔn)確無誤地描述星巴克，而是用基于Web的效勞來講解工作流。好的，既然講清楚了這一點(diǎn)，那么我們現(xiàn)在開頭吧。簡(jiǎn)明陳述由于我們?cè)谥v工作流，所以我們有必要理解構(gòu)成工作流的狀態(tài)〔states〕以及將工作流從一態(tài)機(jī)〔statemachines〕表達(dá)出來了。這兩個(gè)工作流是并行執(zhí)行的。一個(gè)反映了顧客與星巴克效勞之間的交互〔1〕，另一個(gè)刻畫了由咖啡師執(zhí)行的一系列動(dòng)作〔2〕。改菜單，比方說懇求改用半脫脂牛奶。/p>1顧客狀態(tài)機(jī)盡管顧客看不見咖啡師，但咖啡師也有自己的狀態(tài)機(jī)；這個(gè)狀態(tài)機(jī)是效勞實(shí)現(xiàn)私有的。如圖2工作流就完畢了。2咖啡師的狀態(tài)機(jī)WebWebURI轉(zhuǎn)變。GET和HEAD屬于特例，由于它們不引起狀態(tài)遷移。它們的作用是用于查看資源的當(dāng)前狀態(tài)。我們節(jié)奏稍快了點(diǎn)。理解狀態(tài)機(jī)和Web，不是那么簡(jiǎn)潔一口吃個(gè)胖子的。所以，讓我們?cè)赪eb的背景下，來從頭回憶一下整個(gè)場(chǎng)景，逐步漸漸深入。顧客視角我們將從一張簡(jiǎn)潔的故事卡片開頭，它啟動(dòng)整個(gè)流程：這個(gè)故事里涉及一些有用的角色與實(shí)體。首先，里面有“顧客〔Customer〕”角色。明顯，〔StarbucksService〕的消費(fèi)者。其次，里面有兩個(gè)重要的實(shí)體咖啡”和“訂單”〕，以及一個(gè)重要的交互〔“點(diǎn)單”〕——我們的工作流正是由它啟動(dòng)的?！瞨epresentation〕POSTURI“:///order“:///order。3點(diǎn)一杯咖啡圖3顯示了向星巴克點(diǎn)單的交互過程。星巴克承受自己的XML格式來表達(dá)有關(guān)實(shí)體；需要關(guān)注的是，這個(gè)格式允許客戶往里嵌入信息，以便進(jìn)展點(diǎn)單——稍后我們會(huì)看到。實(shí)際提交的4Web〔humanWeb〕HTML〔representationformat〕。HTML有自己特定的語義，全部掃瞄器都理解并承受這些語義，比方：代表“一個(gè)鏈接到其他文檔或本文檔內(nèi)部某個(gè)書簽的錨〔anchor〕”。消費(fèi)者應(yīng)用——掃瞄器——只是HTML，狀態(tài)機(jī)〔也就是你！〕GETPOSTWeb只不過效勞和消費(fèi)者不僅要就交互協(xié)議達(dá)成全都，還要就表示的格式與語義統(tǒng)一意見。4POSTLocation消費(fèi)者。為便利起見，效勞還要把這個(gè)創(chuàng)立的訂單資源的表示〔representation〕也放在響應(yīng)里。發(fā)給消費(fèi)者的響應(yīng)如下所示。5創(chuàng)立好了訂單，等待付款201Created狀態(tài)說明星巴克已經(jīng)成功承受了訂單。Location報(bào)頭給出了創(chuàng)立訂單的URI。響應(yīng)主體里的表示〔representation〕包含了所點(diǎn)飲品及其價(jià)格。另外，這個(gè)表示里還包含另一個(gè)資源的URI——星巴克期望我們與這個(gè)URI交互，以完成顧客工作流；我們稍后將用到它。語義是事先定義好的。WebOK——它的意思是：一切正常；連續(xù)執(zhí)行。Created——我們剛剛創(chuàng)立了一個(gè)資源，一切正常。Accepted——效勞已經(jīng)承受了我們的懇求，并請(qǐng)我們對(duì)LocationURI輪詢〔poll〕。這在異步處理中相當(dāng)有用。303SeeOther——我們需要跟另一個(gè)資源交互，應(yīng)當(dāng)不會(huì)出錯(cuò)。400BadRequest——我們的懇求格式有問題，應(yīng)重格式化后再提交?！不蛘弑Ｃ堋硾]有告知懇求失敗的真實(shí)緣由，但不管什么緣由，我們都得應(yīng)付它?！惨狦ET〕，然后再作打算。412PreconditionFailedEtagIf-Match報(bào)頭的值不滿足條件。我們需要考慮下一步怎么走。417ExpectationFailed——幸虧核查一下，效勞器不將承受你的懇求，所以別真正發(fā)送那個(gè)懇求。500InternalServerError——最偷懶的響應(yīng)。效勞器出錯(cuò)了，而且什么緣由都沒說。祝你不要碰見它。更訂單的時(shí)候。我們來看另一張故事卡片：4，明顯我們?cè)谀抢锓噶艘粋€(gè)錯(cuò)誤：真正愛喝咖啡的人是不寵愛往濃咖啡里放太多熱這樣的轉(zhuǎn)變供給了支持。首先，我們要確認(rèn)我們?nèi)耘f可以修改訂單。有時(shí)咖啡師動(dòng)作很快，在我們想修改訂單之前，時(shí)咖啡師會(huì)比較慢，這樣我們就可以在訂單得到咖啡師處理之前修改它了。為了知道我們是懇求懇求響應(yīng)OPTIONS/order/12341.1Host:200OKAllow:GET,PUT6看看有哪些選擇〔OPTIONS〕6〔支持GET〕、也是可更的〔支持PUT〕。作為好網(wǎng)民，我們可以拿我們的表示來做一次試驗(yàn)性的PUTPUTExpect報(bào)頭來試一試〔7〕。懇求懇求響應(yīng)PUT/order/12341.1Host:starbucks.exampleExpect:100-Continue100Continue7看好再做〔Lookbeforeyouleap〕7417ExpectationFailed。不過，PUT〔如8〕PUT〔representation〕，實(shí)際上就相當(dāng)于修改現(xiàn)有資源。在這個(gè)例子中，PUT一杯濃咖啡。盡管局部更〔partialupdates〕REST處理的。因此，我們沒必要在網(wǎng)絡(luò)上傳送整個(gè)資源表示，我們只要傳送變化的局部即可。8更資源狀態(tài)假設(shè)我們能夠成功提交〔PUT〕更，那么我們會(huì)從效勞器得到響應(yīng)代碼200，如圖9所示。9成功更資源狀態(tài)檢查OPTIONS和承受Expect405409OPTIONSExpectExpectOPTIONS，但有時(shí)PUT工作——有時(shí)他們動(dòng)作很靈敏！PUT操作把更提交給資源時(shí)會(huì)被告知。圖10顯示的就是一個(gè)常見的更失敗的響應(yīng)。409Conflict狀態(tài)代碼說明，假設(shè)承受更，將導(dǎo)致資源處于PUT〔representation〕與效勞端資源狀態(tài)之間的差異。按咖啡制作的話說，加得太晚了——咖啡師已經(jīng)把熱牛奶倒進(jìn)去了。10慢了一步OPTIONSPUTIf-Unmodified-Since或If-MatchIf-Unmodified-SinceIf-MatchETag1。假設(shè)訂單狀態(tài)自從被我們創(chuàng)立以來還沒有轉(zhuǎn)變過——也就是說，咖啡師還沒有開頭制作我們的咖啡——那么更可以處理。假設(shè)訂單狀態(tài)已經(jīng)發(fā)生轉(zhuǎn)變，那么我們會(huì)得到412PreconditionFailed響應(yīng)。雖然我們由于慢了咖啡師一步而只能享用牛奶咖啡，但至少我們沒有把資源轉(zhuǎn)移到不全都的狀態(tài)。PUT〔idempotent〕，這樣我們?cè)谶M(jìn)展?fàn)顟B(tài)更時(shí)就用不著處理一些簡(jiǎn)單事務(wù)了，不過仍有一些選擇需要我們打算。下面是正確進(jìn)展?fàn)顟B(tài)更的一些方法：OPTIONSPUT端，此刻效勞器允許對(duì)該資源做哪些操作，不過這無法保證效勞器將永久支持那些操作。If-Unmodified-SinceIf-MatchPUTPUT412PreconditionFailed。此方法要求：要么資源是緩ETagIf-Unmodified-SinceIf-Match。馬上用PUT操作提交更，并應(yīng)付可能消滅的409Conflict響應(yīng)。就算我們使用了〔1〕和〔2〕，我們可能仍得應(yīng)付這些響應(yīng)，由于我們的“哨兵”和檢查本質(zhì)上都是樂觀的。W3C一個(gè)非標(biāo)準(zhǔn)性文檔ETag。ETags是我們推舉承受的方法。們〔其實(shí)他們也已經(jīng)示意過了！〕，所以我們還需要一張故事卡片：還記得最初那個(gè)針對(duì)原始訂單的響應(yīng)嗎？其中有個(gè)元素。星巴克在訂單資源的表示里面嵌入現(xiàn)在我們應(yīng)當(dāng)進(jìn)一步探討它了：關(guān)于next元素，有幾點(diǎn)是值得指出的。首先，它處于一個(gè)不同的名稱空間之下，由于狀態(tài)遷URI稱空間里，以便于重用〔或甚至最終的標(biāo)準(zhǔn)化〕。其次，rel〔你情愿的話，也可以稱之為一種私有的微格式〕?！?///payment“uri標(biāo)識(shí)的資源轉(zhuǎn)移到工作流里的下一狀態(tài)〔付款〕。uritypeXMLOPTIONSWeb〔如日程表〕的表示〔representations〕。不過，它們同樣也可以便利地被用于集成。微格式術(shù)語是在微格式社10REST作為應(yīng)用狀態(tài)的引擎〔hypermediaastheengineofapplicationstate〕”的關(guān)鍵。更簡(jiǎn)潔地說，URI跟隨鏈接的方式來操作應(yīng)用程序的狀態(tài)機(jī)的。假設(shè)你一時(shí)不能理解，不要感到驚異。這一模型的最不行思議之處在于：狀態(tài)機(jī)和工作流不是像WS-BPEL或WS-CDL那樣事先描述好的，而是在你經(jīng)受各個(gè)狀態(tài)的過程中逐步得到描述〔followinglinks〕這種方式使得我們可以在應(yīng)用的各種狀態(tài)下向前推動(dòng)。每次狀態(tài)遷移時(shí)，當(dāng)前資源的表示里都包含了指向可Web源，所以我們知道如何使用它們。在顧客工作流里，我們下一步要做的是為咖啡付款。我們可以由訂單里的元素得知總金額，消費(fèi)者需要事先把握多少關(guān)于一個(gè)效勞的學(xué)問呢？我們已經(jīng)說過了，效勞和消費(fèi)者在交互之前需要就它們將會(huì)交換的表示〔representations〕〔representationformats〕看成一組可能的狀態(tài)和遷移。在消費(fèi)者與效勞交互時(shí)，效勞選的各個(gè)局部串起來的方式是事先達(dá)成全都的。在設(shè)計(jì)與開發(fā)過程中，消費(fèi)者會(huì)就表示和遷移的語義與效勞器達(dá)成全都。但誰也不能保證效勞在其演化過程中會(huì)不會(huì)承受一種客戶端預(yù)期之外的表示和遷移〔不過客戶端還是知道如何處理它的〕——Web成全都超出了本文的范圍。與之交互〔11〕。懇求懇求響應(yīng)OPTIONS/payment/order/12341.1Host:starbucks.exampleAllow:GET,PUT11獲知如何付款〔〔PUT2來保護(hù)該資源。懇求懇求PUT/payment/order/12341.1Host:starbucks.exampleContent-Type:application/xmlContent-Length:...Authorization:Digestusername=“JaneDoe“realm=““nonce=“...“uri=“payment/order/1234“qop=authnc=00000001cnonce=“...“cnonce=“...“reponse=“...“opaque=“...“12345678907/07JohnCitizen4.00響應(yīng)201CreatedLocation:s://starbucks.example/payment/order/1234Content-Type:application/xmlContent-Length:...12345678907/07JohnCitizen4.0012付款為成功完成付款，我們只需按圖12進(jìn)展交互即可。一旦經(jīng)認(rèn)證的PUT返回一個(gè)201Created響應(yīng)，我們就可以慶祝付款成功、并拿到我們的飲品了。。付款時(shí)可能消滅很多種簡(jiǎn)潔想象的出錯(cuò)狀況：由于效勞器宕機(jī)或其他緣由，我們無法連接上效勞器了；在交互過程中，與效勞器的連接被切斷了；4xx5xx〔假定連接問題是瞬間的〕，我們可以反復(fù)做PUT懇求，直至我們收到成功響應(yīng)為止。假設(shè)前次PUT操作已經(jīng)得到了成功200〔本質(zhì)上是一個(gè)來自效勞器的空操作確認(rèn)〕；假設(shè)本次PUT201500、503504，那么也可以做同樣處理。4xx們通過PUT懇求提交的內(nèi)容無法被效勞器所理解，我們需要訂正后重發(fā)送PUT懇求。403響應(yīng)則相反，它說明效勞器能夠理解我們的懇求，但不知道如何履行〔fulfil〕它，而且服狀態(tài)遷移〔鏈接〕，換其他推動(dòng)狀態(tài)的路線。在這個(gè)例子中，我們已經(jīng)屢次使用狀態(tài)代碼來指引客戶端步向下一個(gè)交互了。狀態(tài)代碼是具的強(qiáng)健性和牢靠性。了。不過整個(gè)故事還沒有完。現(xiàn)在我們進(jìn)入到效勞里面，看看星巴克的內(nèi)部實(shí)現(xiàn)?？Х葞熞暯欠矫婀┙o效勞。依據(jù)我們循序漸進(jìn)的介紹方式，現(xiàn)在該推出另一張故事卡片了。WebAtom〔feeds〕來表達(dá)列表之類的東西是相當(dāng)不錯(cuò)的選擇，它幾乎可描述任何列表〔比方未完成的咖啡訂單〕，所以這里AtomURIGET成的訂單，URI“:///orders“:///orders〔13〕。13待制作飲品的Atom星巴克是家相當(dāng)繁忙的店，位于/orders的Atom提要更相當(dāng)頻繁，所以咖啡師要不斷輪詢這個(gè)提要才能保證把握最信息。輪詢通常被認(rèn)為可伸縮性很差；但是，Web極強(qiáng)的輪詢機(jī)制——我們稍后會(huì)看到。另外，由于星巴克每分鐘要制作很多咖啡，所以承受住負(fù)荷是個(gè)重要問題。這里我們有兩個(gè)相抵觸的需求。一方面，我們期望咖啡師通過常常輪詢訂單提要，以不斷把握最信息；另一方面，我們又不期望給效勞增加負(fù)擔(dān)、或者徒然增加網(wǎng)絡(luò)流量。為防止〔reverseproxy〕來緩存并供給被頻繁訪問的資源表示〔14〕。14通過緩存提升可伸縮性對(duì)于大多數(shù)資源〔尤其是那些會(huì)被很多人訪問的資源，如返回飲品列表的Atom〕，在宿Web〔逆向代理〕，再加上有緩存元數(shù)據(jù)，這樣客戶端獵取資源時(shí)就不會(huì)給原效勞器增加很大負(fù)擔(dān)了。緩存的有利一面是，它屏蔽掉了效勞器的間隙性故障，并通過提高資源可用率來幫助災(zāi)難恢代理緩存起來的。而且，假設(shè)咖啡師漏了某個(gè)訂單的話〔錯(cuò)誤〕，恢復(fù)也很簡(jiǎn)潔進(jìn)展，由于訂單具有很高的可用率。是不太抱負(fù)的。為了把太舊的訂單從緩存中去除，星巴克效勞用Expires13AtomExpires10期。由于這種緩存行為，效勞器每分鐘最多只要響應(yīng)66下〔對(duì)星巴克效勞來說〕，咖啡師的輪詢懇求是由本地緩存響應(yīng)的，這樣就不會(huì)給增加網(wǎng)絡(luò)活動(dòng)或效勞器負(fù)荷了。在我們的例子中，我們只設(shè)置了一個(gè)緩存來幫助提升主咖啡列表的可伸縮性。然而，在真實(shí)的基于Web的場(chǎng)景中，我們可以從多層緩存中受益。要在大規(guī)模環(huán)境中提升可伸縮性，利用WebWeb〔比方外匯交易〕，那WebPUT〔6、7、8、9、10〕。幸運(yùn)地是，我們可以利用一個(gè)已經(jīng)定義好的協(xié)議——Atom〔AtomPublishingProtocolAPPAtomPub〕——來實(shí)現(xiàn)這一目標(biāo)。AtomPubWeb〔基于AtomAtom〔/orders〕里代表咖啡的條目。15咖啡訂單對(duì)應(yīng)的Atom在圖15所示的XML里，有幾點(diǎn)值得留意。首先，它將我們的訂單與Atom提要里的其他訂單區(qū)分開了。其次，其中包含訂單本身，即咖啡師制作咖啡所需的全部信息——包括我們要求增加一杯濃咖啡的重要信息！該訂單對(duì)應(yīng)的entry元素里有個(gè)link元素，它聲明白本條目URI〔這里，可編輯資源的地址剛好跟訂單資源本身的地址一樣，不過這不是必需的?！砋RI來轉(zhuǎn)變訂單資源的狀態(tài)。PUT懇求把經(jīng)修改的資源狀態(tài)提交給這個(gè)編輯URI〔如圖16所示。16AtomPub16PUT/orders/1234GET現(xiàn)在訂單處于穩(wěn)定狀態(tài)了，咖啡師可以毫無顧慮地連續(xù)制作咖啡了。固然，咖啡師只有知道我們已經(jīng)付過款才會(huì)把咖啡給我們，所以咖啡師還要查詢我們是否已經(jīng)完成付款。在真實(shí)的星巴克里，狀況會(huì)略有不同：一般來說，我們是點(diǎn)單后馬上付款的；然后，其他顧客站在以我們來看倒數(shù)其次張故事卡片：咖啡師只要向付款資源〔該資源的URI在訂單表示里給出了〕發(fā)送GET懇求，即可查詢付款狀態(tài)。URI的。但有時(shí)，通過URI模版來訪問資源也很便利。URIURI字符來訪問不同的資源。URIURIs操作，從而對(duì)已保存的制品進(jìn)展操作：“://s3.amazonaws/“://s3.amazonaws/{bucket_name}/{key_name}。〔或其他經(jīng)授權(quán)的星巴克系統(tǒng)〕不用遍歷全部訂單即可訪問各個(gè)付款資源，我URL“:///payment/order/“:///payment/order/{order_id}。URI由于這一潛在的耦合，有些Web集成工作者會(huì)有意避開承受URI模版。我們的建議是，僅當(dāng)URIs〔inferableURIs〕很有幫助而且不會(huì)轉(zhuǎn)變時(shí)才使用。/payments資源的〔不行推斷的〕鏈接。該提要只有經(jīng)授權(quán)的系統(tǒng)才能讀取。URI固然，不是人人都可以查看付款信息的。我們不想讓咖啡社區(qū)里會(huì)動(dòng)歪腦筋的人查看他人的Web要求它供給證書?！?7〕懇求懇求響應(yīng)GET/payment/order/12341.1Host:401UnauthorizedWWW-Authenticate:Digestrealm=““,qop=“auth“,nonce=“ab656...“,opaque=“b6a9...“17應(yīng)付款資源的非授權(quán)訪問受到質(zhì)詢401〔及其認(rèn)證元數(shù)據(jù)〕告知我們，我們應(yīng)當(dāng)在懇求里附上正確的證書、然后重發(fā)送18〕后，我們得到了付款信息，并將之與代表訂單總“:///total/order/1234“:///total/order/1234進(jìn)展比較。懇求懇求響應(yīng)200OKContent-Type:GET/payment/order/12341.1Host:Content-Length:...application/xmlAuthorization:Digestusername=“baristajoe“realm=““nonce=“...“uri=“payment/order/1234“qop=authnc=00000001cnonce=“...“ 12345678907/07reponse=“...“opaque=“...“ JohnCitizen4.0018授權(quán)訪問付款資源如同前面一樣，我們承受一個(gè)故事來講解這個(gè)回合：由于訂單提要里的各個(gè)條目〔entry〕URI，所以我DELETE懇求懇求響應(yīng)DELETE/order/12341.1Host:200OK19刪除已完成的訂單GET刪除〔DELETE〕的資源。假定我們的緩存工作正常、且我們已經(jīng)設(shè)置了合理的緩存過期元數(shù)據(jù)的話，那么當(dāng)你試圖獵取〔GET〕404NotFound們想直接把位于/ordersAtomAtom提要公布飲品訂單、甚至修改訂單了。演化：Web上的現(xiàn)實(shí)狀況由于我們的咖啡店是基于自描述的狀態(tài)機(jī)〔statemachines〕構(gòu)建起來的，所以我們可以便利地依據(jù)業(yè)務(wù)需要改造我們的工作流。例如，星巴克或許會(huì)供給一種免費(fèi)的網(wǎng)上促銷活動(dòng)：表示〔representation〕。消費(fèi)者知道用這些格式與表示跟我們的效勞進(jìn)展交互。8〔representation〕。我們的咖啡工作流將進(jìn)展更，以包含指向該網(wǎng)上促銷資源的鏈接。由于URI的特性，鏈接可以是指向第三方的——這跟指向星巴克內(nèi)部的資源一樣簡(jiǎn)潔。過它們可能無法享受促銷而已，由于這局部還沒有寫進(jìn)它們的代碼里去。9成功進(jìn)展演化的關(guān)鍵在于，效勞的消費(fèi)者們要能夠預(yù)料到轉(zhuǎn)變。在每一步，效勞不是直接跟〔namedresources〕URIs，以便消費(fèi)者與之交互。這些具名資源，有些是消費(fèi)者不生疏的、將被無視的，有些是消費(fèi)者還能維持與消費(fèi)者兼容。你將使用的是一個(gè)相當(dāng)熱門的技術(shù)〔也可能無法修改〕、付我們可以用Web來描述全部必需的交互。我們可以利用現(xiàn)有的Web模型處理一些簡(jiǎn)潔的不開心機(jī)制——我們所需的一切都是現(xiàn)成供給的。而且，即便發(fā)生了那些不開心的事，客戶端仍舊可以向它們的目標(biāo)邁進(jìn)。