星巴克REST案例分析

如何猎取〔GET〕一杯咖啡REST我们已习惯于在大型中间件平台〔CORBA、WebJ2EE的平台〕之上构建分布Web运行的协议和文档格式视为一种应-Web在WebGET/connected-Web-basedintegration〔暂定名称〕里的一些想法。引言Web好的集成由什么构成”的观念。集成〔integration〕并不是一种夹在系统之间的专业活动；与此相反，现在，集成是成功方案里的不行缺少的一局部。然而，仍有很多人误会并低估Web在企业计算中的作用。即便是那些精通Web的人士，也常常要花费很大力气才能懂得，WebXMLoverRPCWeb的用处；它实际上是一个强健的集成平台。平台，它能够对企业系统做很“酷”的事。另外，工作流是企业软件最具代表性的特征。为什么要工作流？〔至少在计算方面〕。工作流把一项工作〔work〕划分为多个离散的步骤〔steps〕以及触发步骤转移的大事〔events〕。工作流所实现的整个业务流程常常跨越假设干企业信息系统，这给工作流带来很多集成问题。星巴克：统一标准的咖啡需要统一标准的集成的交互，以实现更大的业务力量。要恰如其份地介绍工作流，就免不了表达一大堆跟领域相关的技术细节，而这不是本文的主旨，因此，我们选择了GregorHohpe的星巴克工作流这个比较好理解的例子来举例说明基于WebGregor成一个解耦合的〔decoupled〕盈利生产线的：上面作上记号说明你点的是什么，然后把这个杯子放到队列里去。这里的队列指的是在咖啡忙不过来的时候，收银员仍旧可以为顾客点单。他们可以在繁忙时段安排多个咖啡师，就像竞争消费者模式〔CompetingConsumer〕里那样。”GregorEAI〔如面对消息的中间件〕Web源〔支持统一接口的可寻址实体〕Web具有跟传统EAI工具一样的牢靠性，以及何以不仅仅是恳求/响应协议之上的XML消息传递！首先，我们很内疚擅自设想了星巴克的工作流程，由于我们的目的并不是准确无误地描述星巴克，而是用基于Web的效劳来讲解工作流。好的，既然讲清楚了这一点，那么我们现在开头吧。简明陈述由于我们在讲工作流，所以我们有必要理解构成工作流的状态〔states〕以及将工作流从一态机〔statemachines〕表达出来了。这两个工作流是并行执行的。一个反映了顾客与星巴克效劳之间的交互〔1〕，另一个刻画了由咖啡师执行的一系列动作〔2〕。改菜单，比方说恳求改用半脱脂牛奶。/p>1顾客状态机尽管顾客看不见咖啡师，但咖啡师也有自己的状态机；这个状态机是效劳实现私有的。如图2工作流就完毕了。2咖啡师的状态机WebWebURI转变。GET和HEAD属于特例，由于它们不引起状态迁移。它们的作用是用于查看资源的当前状态。我们节奏稍快了点。理解状态机和Web，不是那么简洁一口吃个胖子的。所以，让我们在Web的背景下，来从头回忆一下整个场景，逐步渐渐深入。顾客视角我们将从一张简洁的故事卡片开头，它启动整个流程：这个故事里涉及一些有用的角色与实体。首先，里面有“顾客〔Customer〕”角色。明显，〔StarbucksService〕的消费者。其次，里面有两个重要的实体咖啡”和“订单”〕，以及一个重要的交互〔“点单”〕——我们的工作流正是由它启动的。〔representation〕POSTURI“:///order“:///order。3点一杯咖啡图3显示了向星巴克点单的交互过程。星巴克承受自己的XML格式来表达有关实体；需要关注的是，这个格式允许客户往里嵌入信息，以便进展点单——稍后我们会看到。实际提交的4Web〔humanWeb〕HTML〔representationformat〕。HTML有自己特定的语义，全部扫瞄器都理解并承受这些语义，比方：代表“一个链接到其他文档或本文档内部某个书签的锚〔anchor〕”。消费者应用——扫瞄器——只是HTML，状态机〔也就是你！〕GETPOSTWeb只不过效劳和消费者不仅要就交互协议达成全都，还要就表示的格式与语义统一意见。4POSTLocation消费者。为便利起见，效劳还要把这个创立的订单资源的表示〔representation〕也放在响应里。发给消费者的响应如下所示。5创立好了订单，等待付款201Created状态说明星巴克已经成功承受了订单。Location报头给出了创立订单的URI。响应主体里的表示〔representation〕包含了所点饮品及其价格。另外，这个表示里还包含另一个资源的URI——星巴克期望我们与这个URI交互，以完成顾客工作流；我们稍后将用到它。语义是事先定义好的。WebOK——它的意思是：一切正常；连续执行。Created——我们刚刚创立了一个资源，一切正常。Accepted——效劳已经承受了我们的恳求，并请我们对LocationURI轮询〔poll〕。这在异步处理中相当有用。303SeeOther——我们需要跟另一个资源交互，应当不会出错。400BadRequest——我们的恳求格式有问题，应重格式化后再提交。〔或者保密〕没有告知恳求失败的真实缘由，但不管什么缘由，我们都得应付它。〔要GET〕，然后再作打算。412PreconditionFailedEtagIf-Match报头的值不满足条件。我们需要考虑下一步怎么走。417ExpectationFailed——幸亏核查一下，效劳器不将承受你的恳求，所以别真正发送那个恳求。500InternalServerError——最偷懒的响应。效劳器出错了，而且什么缘由都没说。祝你不要碰见它。更订单的时候。我们来看另一张故事卡片：4，明显我们在那里犯了一个错误：真正爱喝咖啡的人是不宠爱往浓咖啡里放太多热这样的转变供给了支持。首先，我们要确认我们仍旧可以修改订单。有时咖啡师动作很快，在我们想修改订单之前，时咖啡师会比较慢，这样我们就可以在订单得到咖啡师处理之前修改它了。为了知道我们是恳求恳求响应OPTIONS/order/12341.1Host:200OKAllow:GET,PUT6看看有哪些选择〔OPTIONS〕6〔支持GET〕、也是可更的〔支持PUT〕。作为好网民，我们可以拿我们的表示来做一次试验性的PUTPUTExpect报头来试一试〔7〕。恳求恳求响应PUT/order/12341.1Host:starbucks.exampleExpect:100-Continue100Continue7看好再做〔Lookbeforeyouleap〕7417ExpectationFailed。不过，PUT〔如8〕PUT〔representation〕，实际上就相当于修改现有资源。在这个例子中，PUT一杯浓咖啡。尽管局部更〔partialupdates〕REST处理的。因此，我们没必要在网络上传送整个资源表示，我们只要传送变化的局部即可。8更资源状态假设我们能够成功提交〔PUT〕更，那么我们会从效劳器得到响应代码200，如图9所示。9成功更资源状态检查OPTIONS和承受Expect405409OPTIONSExpectExpectOPTIONS，但有时PUT工作——有时他们动作很灵敏！PUT操作把更提交给资源时会被告知。图10显示的就是一个常见的更失败的响应。409Conflict状态代码说明，假设承受更，将导致资源处于PUT〔representation〕与效劳端资源状态之间的差异。按咖啡制作的话说，加得太晚了——咖啡师已经把热牛奶倒进去了。10慢了一步OPTIONSPUTIf-Unmodified-Since或If-MatchIf-Unmodified-SinceIf-MatchETag1。假设订单状态自从被我们创立以来还没有转变过——也就是说，咖啡师还没有开头制作我们的咖啡——那么更可以处理。假设订单状态已经发生转变，那么我们会得到412PreconditionFailed响应。虽然我们由于慢了咖啡师一步而只能享用牛奶咖啡，但至少我们没有把资源转移到不全都的状态。PUT〔idempotent〕，这样我们在进展状态更时就用不着处理一些简单事务了，不过仍有一些选择需要我们打算。下面是正确进展状态更的一些方法：OPTIONSPUT端，此刻效劳器允许对该资源做哪些操作，不过这无法保证效劳器将永久支持那些操作。If-Unmodified-SinceIf-MatchPUTPUT412PreconditionFailed。此方法要求：要么资源是缓ETagIf-Unmodified-SinceIf-Match。马上用PUT操作提交更，并应付可能消灭的409Conflict响应。就算我们使用了〔1〕和〔2〕，我们可能仍得应付这些响应，由于我们的“哨兵”和检查本质上都是乐观的。W3C一个非标准性文档ETag。ETags是我们推举承受的方法。们〔其实他们也已经示意过了！〕，所以我们还需要一张故事卡片：还记得最初那个针对原始订单的响应吗？其中有个元素。星巴克在订单资源的表示里面嵌入现在我们应当进一步探讨它了：关于next元素，有几点是值得指出的。首先，它处于一个不同的名称空间之下，由于状态迁URI称空间里，以便于重用〔或甚至最终的标准化〕。其次，rel〔你情愿的话，也可以称之为一种私有的微格式〕。“:///payment“uri标识的资源转移到工作流里的下一状态〔付款〕。uritypeXMLOPTIONSWeb〔如日程表〕的表示〔representations〕。不过，它们同样也可以便利地被用于集成。微格式术语是在微格式社10REST作为应用状态的引擎〔hypermediaastheengineofapplicationstate〕”的关键。更简洁地说，URI跟随链接的方式来操作应用程序的状态机的。假设你一时不能理解，不要感到惊异。这一模型的最不行思议之处在于：状态机和工作流不是像WS-BPEL或WS-CDL那样事先描述好的，而是在你经受各个状态的过程中逐步得到描述〔followinglinks〕这种方式使得我们可以在应用的各种状态下向前推动。每次状态迁移时，当前资源的表示里都包含了指向可Web源，所以我们知道如何使用它们。在顾客工作流里，我们下一步要做的是为咖啡付款。我们可以由订单里的元素得知总金额，消费者需要事先把握多少关于一个效劳的学问呢？我们已经说过了，效劳和消费者在交互之前需要就它们将会交换的表示〔representations〕〔representationformats〕看成一组可能的状态和迁移。在消费者与效劳交互时，效劳选的各个局部串起来的方式是事先达成全都的。在设计与开发过程中，消费者会就表示和迁移的语义与效劳器达成全都。但谁也不能保证效劳在其演化过程中会不会承受一种客户端预期之外的表示和迁移〔不过客户端还是知道如何处理它的〕——Web成全都超出了本文的范围。与之交互〔11〕。恳求恳求响应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响应201CreatedLocation:s://starbucks.example/payment/order/1234Content-Type:application/xmlContent-Length:...12345678907/07JohnCitizen4.0012付款为成功完成付款，我们只需按图12进展交互即可。一旦经认证的PUT返回一个201Created响应，我们就可以庆祝付款成功、并拿到我们的饮品了。。付款时可能消灭很多种简洁想象的出错状况：由于效劳器宕机或其他缘由，我们无法连接上效劳器了；在交互过程中，与效劳器的连接被切断了；4xx5xx〔假定连接问题是瞬间的〕，我们可以反复做PUT恳求，直至我们收到成功响应为止。假设前次PUT操作已经得到了成功200〔本质上是一个来自效劳器的空操作确认〕；假设本次PUT201500、503504，那么也可以做同样处理。4xx们通过PUT恳求提交的内容无法被效劳器所理解，我们需要订正后重发送PUT恳求。403响应则相反，它说明效劳器能够理解我们的恳求，但不知道如何履行〔fulfil〕它，而且服状态迁移〔链接〕，换其他推动状态的路线。在这个例子中，我们已经屡次使用状态代码来指引客户端步向下一个交互了。状态代码是具的强健性和牢靠性。了。不过整个故事还没有完。现在我们进入到效劳里面，看看星巴克的内部实现。咖啡师视角方面供给效劳。依据我们循序渐进的介绍方式，现在该推出另一张故事卡片了。WebAtom〔feeds〕来表达列表之类的东西是相当不错的选择，它几乎可描述任何列表〔比方未完成的咖啡订单〕，所以这里AtomURIGET成的订单，URI“:///orders“:///orders〔13〕。13待制作饮品的Atom星巴克是家相当繁忙的店，位于/orders的Atom提要更相当频繁，所以咖啡师要不断轮询这个提要才能保证把握最信息。轮询通常被认为可伸缩性很差；但是，Web极强的轮询机制——我们稍后会看到。另外，由于星巴克每分钟要制作很多咖啡，所以承受住负荷是个重要问题。这里我们有两个相抵触的需求。一方面，我们期望咖啡师通过常常轮询订单提要，以不断把握最信息；另一方面，我们又不期望给效劳增加负担、或者徒然增加网络流量。为防止〔reverseproxy〕来缓存并供给被频繁访问的资源表示〔14〕。14通过缓存提升可伸缩性对于大多数资源〔尤其是那些会被很多人访问的资源，如返回饮品列表的Atom〕，在宿Web〔逆向代理〕，再加上有缓存元数据，这样客户端猎取资源时就不会给原效劳器增加很大负担了。缓存的有利一面是，它屏蔽掉了效劳器的间隙性故障，并通过提高资源可用率来帮助灾难恢代理缓存起来的。而且，假设咖啡师漏了某个订单的话〔错误〕，恢复也很简洁进展，由于订单具有很高的可用率。是不太抱负的。为了把太旧的订单从缓存中去除，星巴克效劳用Expires13AtomExpires10期。由于这种缓存行为，效劳器每分钟最多只要响应66下〔对星巴克效劳来说〕，咖啡师的轮询恳求是由本地缓存响应的，这样就不会给增加网络活动或效劳器负荷了。在我们的例子中，我们只设置了一个缓存来帮助提升主咖啡列表的可伸缩性。然而，在真实的基于Web的场景中，我们可以从多层缓存中受益。要在大规模环境中提升可伸缩性，利用WebWeb〔比方外汇交易〕，那WebPUT〔6、7、8、9、10〕。幸运地是，我们可以利用一个已经定义好的协议——Atom〔AtomPublishingProtocolAPPAtomPub〕——来实现这一目标。AtomPubWeb〔基于AtomAtom〔/orders〕里代表咖啡的条目。15咖啡订单对应的Atom在图15所示的XML里，有几点值得留意。首先，它将我们的订单与Atom提要里的其他订单区分开了。其次，其中包含订单本身，即咖啡师制作咖啡所需的全部信息——包括我们要求增加一杯浓咖啡的重要信息！该订单对应的entry元素里有个link元素，它声明白本条目URI〔这里，可编辑资源的地址刚好跟订单资源本身的地址一样，不过这不是必需的。〕URI来转变订单资源的状态。PUT恳求把经修改的资源状态提交给这个编辑URI〔如图16所示。16AtomPub16PUT/orders/1234GET现在订单处于稳定状态了，咖啡师可以毫无顾虑地连续制作咖啡了。固然，咖啡师只有知道我们已经付过款才会把咖啡给我们，所以咖啡师还要查询我们是否已经完成付款。在真实的星巴克里，状况会略有不同：一般来说，我们是点单后马上付款的；然后，其他顾客站在以我们来看倒数其次张故事卡片：咖啡师只要向付款资源〔该资源的URI在订单表示里给出了〕发送GET恳求，即可查询付款状态。URI的。但有时，通过URI模版来访问资源也很便利。URIURI字符来访问不同的资源。URIURIs操作，从而对已保存的制品进展操作：“://s3.amazonaws/“://s3.amazonaws/{bucket_name}/{key_name}。〔或其他经授权的星巴克系统〕不用遍历全部订单即可访问各个付款资源，我URL“:///payment/order/“:///payment/order/{order_id}。URI由于这一潜在的耦合，有些Web集成工作者会有意避开承受URI模版。我们的建议是，仅当URIs〔inferableURIs〕很有帮助而且不会转变时才使用。/payments资源的〔不行推断的〕链接。该提要只有经授权的系统才能读取。URI固然，不是人人都可以查看付款信息的。我们不想让咖啡社区里会动歪脑筋的人查看他人的Web要求它供给证书。〔17〕恳求恳求响应GET/payment/order/12341.1Host:401UnauthorizedWWW-Authenticate:Digestrealm=““,qop=“auth“,nonce=“ab656...“,opaque=“b6a9...“17应付款资源的非授权访问受到质询401〔及其认证元数据〕告知我们，我们应当在恳求里附上正确的证书、然后重发送18〕后，我们得到了付款信息，并将之与代表订单总“:///total/order/1234“:///total/order/1234进展比较。恳求恳求响应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授权访问付款资源如同前面一样，我们承受一个故事来讲解这个回合：由于订单提要里的各个条目〔entry〕URI，所以我DELETE恳求恳求响应DELETE/order/12341.1Host:200OK19删除已完成的订单GET删除〔DELETE〕的资源。假定我们的缓存工作正常、且我们已经设置了合理的缓存过期元数据的话，那么当你试图猎取〔GET〕404NotFound们想直接把位于/ordersAtomAtom提要公布饮品订单、甚至修改订单了。演化：Web上的现实状况由于我们的咖啡店是基于自描述的状态机〔statemachines〕构建起来的，所以我们可以便利地依据业务需要改造我们的工作流。例如，星巴克或许会供给一种免费的网上促销活动：表示〔representation〕。消费者知道用这些格式与表示跟我们的效劳进展交互。8〔representation〕。我们的咖啡工作流将进展更，以包含指向该网上促销资源的链接。由于URI的特性，链接可以是指向第三方的——这跟指向星巴克内部的资源一样简洁。过它们可能无法享受促销而已，由于这局部还没有写进它们的代码里去。9成功进展演化的关键在于，效劳的消费者们要能够预料到转变。在每一步，效劳不是直接跟〔namedresources〕URIs，以便消费者与之交互。这些具名资源，有些是消费者不生疏的、将被无视的，有些是消费者还能维持与消费者兼容。你将使用的是一个相当热门的技术〔也可能无法修改〕、付我们可以用Web来描述全部必需的交互。我们可以利用现有的Web模型处理一些简洁的不开心机制——我们所需的一切都是现成供给的。而且，即便发生了那些不开心的事，客户端仍旧可以向它们的目标迈进。