星巴克REST案例分析

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