<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    gembin

    OSGi, Eclipse Equinox, ECF, Virgo, Gemini, Apache Felix, Karaf, Aires, Camel, Eclipse RCP

    HBase, Hadoop, ZooKeeper, Cassandra

    Flex4, AS3, Swiz framework, GraniteDS, BlazeDS etc.

    There is nothing that software can't fix. Unfortunately, there is also nothing that software can't completely fuck up. That gap is called talent.

    About Me

     

    Building Web Services the REST Way

    Building Web Services the REST Way

    Roger L. Costello

    I will first provide a brief introduction to REST and then describe how to build Web services in the REST style.

    What is REST?

    REST is a term coined by Roy Fielding in his Ph.D. dissertation [1] to describe an architecture style of networked systems. REST is an acronym standing for Representational State Transfer.

    Why is it called Representational State Transfer?

    The Web is comprised of resources. A resource is any item of interest. For example, the Boeing Aircraft Corp may define a 747 resource. Clients may access that resource with this URL:
    http://www.boeing.com/aircraft/747
    A representation of the resource is returned (e.g., Boeing747.html). The representation places the client application in a state. The result of the client traversing a hyperlink in Boeing747.html is another resource is accessed. The new representation places the client application into yet another state. Thus, the client application changes (transfers) state with each resource representation --> Representational State Transfer! Here is Roy Fielding's explanation of the meaning of Representational State Transfer: "Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use."

    Motivation for REST

    The motivation for REST was to capture the characteristics of the Web which made the Web successful. Subsequently these characteristics are being used to guide the evolution of the Web.

    REST - An Architectural Style, Not a Standard

    REST is not a standard. You will not see the W3C putting out a REST specification. You will not see IBM or Microsoft or Sun selling a REST developer's toolkit. Why? Because REST is just an architectural style. You can't bottle up that style. You can only understand it, and design your Web services in that style. (Analogous to the client-server architectural style. There is no client-server standard.) While REST is not a standard, it does use standards:
    • HTTP
    • URL
    • XML/HTML/GIF/JPEG/etc (Resource Representations)
    • text/xml, text/html, image/gif, image/jpeg, etc (MIME Types)

    The Classic REST System

    The Web is a REST system! Many of those Web services that you have been using these many years - book-ordering services, search services, online dictionary services, etc - are REST-based Web services. Alas, you have been using REST, building REST services and you didn't even know it. REST is concerned with the "big picture" of the Web. It does not deal with implementation details (e.g., using Java servlets or CGI to implement a Web service). So let's look at an example of creating a Web service from the REST "big picture" perspective.

    Parts Depot Web Services

    Parts Depot, Inc (fictitious company) has deployed some web services to enable its customers to:
    • get a list of parts
    • get detailed information about a particular part
    • submit a Purchase Order (PO)
    Let's consider how each of these services are implemented in a RESTful fashion.

    Get Parts List

    The web service makes available a URL to a parts list resource. For example, a client would use this URL to get the parts list:
    http://www.parts-depot.com/parts
    Note that "how" the web service generates the parts list is completely transparent to the client. All the client knows is that if he/she submits the above URL then a document containing the list of parts is returned. Since the implementation is transparent to clients, Parts Depot is free to modify the underlying implementation of this resource without impacting clients. This is loose coupling.

    Here's the document that the client receives:

    <?xml version="1.0"?>
    <p:Parts xmlns:p="http://www.parts-depot.com"
    xmlns:xlink="http://www.w3.org/1999/xlink">
    <Part id="00345" xlink:/>
    <Part id="00346" xlink:/>
    <Part id="00347" xlink:/>
    <Part id="00348" xlink:/>
    </p:Parts>
    [Assume that through content negotiation the service determined that the client wants the representation as XML (for machine-to-machine processing).] Note that the parts list has links to get detailed info about each part. This is a key feature of REST. The client transfers from one state to the next by examining and choosing from among the alternative URLs in the response document.

    Get Detailed Part Data

    The web service makes available a URL to each part resource. Example, here's how a client requests part 00345:
    http://www.parts-depot.com/parts/00345
    Here's the document that the client receives:
    <?xml version="1.0"?>
    <p:Part xmlns:p="http://www.parts-depot.com"
    xmlns:xlink="http://www.w3.org/1999/xlink">
    <Part-ID>00345</Part-ID>
    <Name>Widget-A</Name>
    <Description>This part is used within the frap assembly</Description>
    <Specification xlink:/>
    <UnitCost currency="USD">0.10</UnitCost>
    <Quantity>10</Quantity>
    </p:Part>
    Again observe how this data is linked to still more data - the specification for this part may be found by traversing the hyperlink. Each response document allows the client to drill down to get more detailed information.

    Submit PO

    The web service makes available a URL to submit a PO. The client creates a PO instance document which conforms to the PO schema that Parts Depot has designed (and publicized in a WSDL document). The client submits PO.xml as the payload of an HTTP POST.
    The PO service responds to the HTTP POST with a URL to the submitted PO. Thus, the client can retrieve the PO any time thereafter (to update/edit it). The PO has become a piece of information which is shared between the client and the server. The shared information (PO) is given an address (URL) by the server and is exposed as a Web service.

    Logical URLs versus Physical URLs

    A resource is a conceptual entity. A representation is a concrete manifestation of the resource. This URL:
    http://www.parts-depot.com/parts/00345
    is a logical URL, not a physical URL. Thus, there doesn't need to be, for example, a static HTML page for each part. In fact, if there were a million parts then a million static HTML pages would not be a very attractive design. [Implementation detail: Parts Depot could implement the service that gets detailed data about a particular part by employing a Java Servlet which parses the string after the host name, uses the part number to query the parts database, formulate the query results as XML, and then return the XML as the payload of the HTTP response.] As a matter of style URLs should not reveal the implementation technique used. You need to be free to change your implementation without impacting clients or having misleading URLs.

    REST Web Services Characteristics

    Here are the characteristics of REST:
    • Client-Server: a pull-based interaction style: consuming components pull representations.
    • Stateless: each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server.
    • Cache: to improve network efficiency responses must be capable of being labeled as cacheable or non-cacheable.
    • Uniform interface: all resources are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE).
    • Named resources - the system is comprised of resources which are named using a URL.
    • Interconnected resource representations - the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.
    • Layered components - intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.

    Principles of REST Web Service Design

    1. The key to creating Web Services in a REST network (i.e., the Web) is to identify all of the conceptual entities that you wish to expose as services. Above we saw some examples of resources: parts list, detailed part data, purchase order.

    2. Create a URL to each resource. The resources should be nouns, not verbs. For example, do not use this:

    http://www.parts-depot.com/parts/getPart?id=00345
    Note the verb, getPart. Instead, use a noun:
    http://www.parts-depot.com/parts/00345
    3. Categorize your resources according to whether clients can just receive a representation of the resource, or whether clients can modify (add to) the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE. 4. All resources accessible via HTTP GET should be side-effect free. That is, the resource should just return a representation of the resource. Invoking the resource should not result in modifying the resource. 5. No man/woman is an island. Likewise, no representation should be an island. In other words, put hyperlinks within resource representations to enable clients to drill down for more information, and/or to obtain related information. 6. Design to reveal data gradually. Don't reveal everything in a single response document. Provide hyperlinks to obtain more details. 7. Specify the format of response data using a schema (DTD, W3C Schema, RelaxNG, or Schematron). For those services that require a POST or PUT to it, also provide a schema to specify the format of the response. 8. Describe how your services are to be invoked using either a WSDL document, or simply an HTML document.

    Summary

    This article described REST as an architectural style. In fact, it's the architectural style of the Web. REST describes what makes the Web work well. Adhering to the REST principles will make your services work well in the context of the Web. In a future article I will write about the evolution of the Web using the REST principles.

    Acknowledgement

    Thanks to Robert Leftwich and Philip Eskelin for their very helpful comments in creating this document.

    References

    [1] http://www.ebuilt.com/fielding/pubs/dissertation/top.htm

    posted on 2008-09-11 14:04 gembin 閱讀(358) 評(píng)論(0)  編輯  收藏 所屬分類: Web Service


    只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。


    網(wǎng)站導(dǎo)航:
     

    導(dǎo)航

    統(tǒng)計(jì)

    常用鏈接

    留言簿(6)

    隨筆分類(440)

    隨筆檔案(378)

    文章檔案(6)

    新聞檔案(1)

    相冊(cè)

    收藏夾(9)

    Adobe

    Android

    AS3

    Blog-Links

    Build

    Design Pattern

    Eclipse

    Favorite Links

    Flickr

    Game Dev

    HBase

    Identity Management

    IT resources

    JEE

    Language

    OpenID

    OSGi

    SOA

    Version Control

    最新隨筆

    搜索

    積分與排名

    最新評(píng)論

    閱讀排行榜

    評(píng)論排行榜

    free counters 主站蜘蛛池模板: 亚洲视频精品在线观看| 亚洲色欲久久久久综合网| jizz中国免费| 又粗又长又爽又长黄免费视频 | 久久精品熟女亚洲av麻豆| 中文字幕无码成人免费视频| 女人18毛片水最多免费观看| 亚洲AV成人潮喷综合网| 边摸边脱吃奶边高潮视频免费| 久久大香香蕉国产免费网站| 亚洲日韩精品无码一区二区三区| 亚洲国色天香视频| 3d动漫精品啪啪一区二区免费| 免费中文字幕在线| 337p欧洲亚洲大胆艺术| 精品成在人线AV无码免费看 | 无码人妻一区二区三区免费视频| 免费一级毛片在播放视频| 一级毛片免费不卡直观看| a毛片基地免费全部视频| 亚洲www77777| 日本卡1卡2卡三卡免费| 亚洲黄色片在线观看| 99精品国产免费久久久久久下载| 亚洲人成色99999在线观看| 免费国内精品久久久久影院| 一级毛片大全免费播放下载| 国产l精品国产亚洲区在线观看| 久久国产精品成人片免费| 亚洲一区二区三区在线播放| 成人免费区一区二区三区| 亚洲欧洲日本精品| 国产免费牲交视频| 国产精品免费AV片在线观看| 亚洲乱码一区av春药高潮| 97在线视频免费公开观看| 亚洲中文字幕无码mv| 无限动漫网在线观看免费| 日韩免费在线中文字幕| 久久久国产精品亚洲一区| 9久热精品免费观看视频|