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

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

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

    走自己的路

    路漫漫其修遠兮,吾將上下而求索

      BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
      50 隨筆 :: 4 文章 :: 118 評論 :: 0 Trackbacks
     

    Rest and Restful web services

    There are currently two schools of thought in developing web services: the traditional, standards-based approach (SOAP) and conceptually simpler and the trendier new kid on the block (REST). The origin of the term "REST" comes from the famous thesis from Roy Fielding describing the concept of Representative State Transfer (REST). REST is an architectural style that can be summed up as four verbs (GET, POST, PUT, and DELETE from HTTP 1.1) and the nouns, which are the resources available on the network (referenced in the URI). The verbs have the following operational equivalents:

    HTTP     CRUD Equivalent

    ==============================

    GET      read

    POST     create,update,delete

    PUT      create,update

    DELETE   delete

    The emergence of the RESTful style of web services was a reaction to the more heavy-weight SOAP-based standards. In RESTful web services, the emphasis is on simple point-to-point communication over HTTP using plain old XML (POX) or JSON.

    Java API for RESTful Web Services specification is in final state, JAX-RS is an annotation-based API for implementing RESTful web services, based on HTTP. In addition to the Sun-provided reference implementation, Jersey, other implementations are available (in various stages of completion): as part of the popular Restlet framework, the JBoss RESTeasy project , and as part of the Apache CXF web services stack.

    Rest vs SOAP:

    Representation

    A REST-style web service might be every bit as subtle and complicated as a SOAP-based service. The RESTful approach tries to simplify matters by taking what HTTP, with its MIME type system, already offers: built-in CRUD operations, uniformly identifiable resources, and typed representations that can capture a resource's state. The key to the REST methodology is to write Web services using a representation that is already well known and widely used: the URI.

    Complexity

    REST as a design philosophy tries to isolate application complexity at the endpoints, that is, at the client and at the service. A service may require lots of logic and computation to maintain resources and to generate adequate representation of resources—for instance, large and subtly formatted XML documents—and a client may require significant XML processing to extract the desired information from the XML representations transferred from the service to the client.

    Bandwidth

    RESTful approach keeps the complexity out of the transport level, as a resource representation is transferred to the client as the body of an HTTP response message. By contrast, a SOAP-based service inevitably complicates the transport level because a SOAP message is encapsulated as the body of a transport message; for instance, an HTTP or SMTP message. SOAP requires messages within messages, whereas REST does not.

    Performance

    SOAP uses XML generally bloats your messages quite a bit.

    Something like POX or JSON would be more compact and maybe faster to serialize / deserialize.

    Payloads of SOAP are significantly larger which are slower to assemble, transport, parse, validate and process.

    Security

    A typical SOAP request will use POST to communicate with a given service. And without looking into the SOAP envelope, there's no way to know whether that request simply wants to query data or delete entire tables from the database

    As for authentication and authorization, SOAP places the burden in the hands of the application developer. The REST methodology instead takes into account the fact that Web servers already have support for these tasks.

    Domain Design

    SOAP services defined in Web Services Description Language (WSDL) emphasize contracts and actions. In contrast, REST focuses on direct addressing and manipulation of resources, which is more compatible with the domain-driven approach.

    Defects

    l           There is less definition of interface, especially the method interface

    l           Hard to make strongly typed objects to work with it in server side code  

    l           Only works over HTTP, but SOAP can work on HTTP, FTP, MIME, JMS, SMTP and etc

    l           Calls to REST are restricted by HTTP Verbs (GET, POST, PUT, DELETE.. etc)

    l           No automatic xml schema validation

    l           Less SOA-style than SOAP

    l           Developer has less control on security than SOAP, SOAP has ws-*(ws-security, ws-trust, ws-policy and etc), SAML, XACML and etc

    l           Routing is network-controlled, but SOAP can make client to control routing explicitly through SOAP headers, WS-Addressing and etc

    Implementation

    How to implement Restful web services, there are three kinds of methods recently:

    • Make use of provider and dispatch twins of SOAP-based web service
    • Implement Restful HTTPServlets
    • JAX-RS, annotation-based implementation


    主站蜘蛛池模板: 久久亚洲欧洲国产综合| 毛片免费在线播放| 免费无码又爽又刺激网站 | 国产午夜鲁丝片AV无码免费| 猫咪社区免费资源在线观看| 麻豆一区二区免费播放网站| 成年大片免费视频| 免费激情视频网站| 免费理论片51人人看电影| 国产大片线上免费看| 亚洲国产a级视频| 一本色道久久综合亚洲精品高清| 在线观看国产区亚洲一区成人| 亚洲色婷婷综合久久| 亚洲成人激情在线| 亚洲宅男天堂a在线| 亚洲一卡2卡3卡4卡5卡6卡| 精品亚洲国产成人av| 免费无码又爽又黄又刺激网站| igao激情在线视频免费| a级毛片毛片免费观看久潮| 久久伊人免费视频| 国产麻豆视频免费观看| 日韩成人在线免费视频 | 最近中文字幕电影大全免费版| 亚洲免费观看网站| 日韩精品免费一区二区三区| 久久国产成人亚洲精品影院| 久久亚洲国产伦理| 亚洲成A人片在线播放器| 亚洲爆乳少妇无码激情| 九九热久久免费视频| 最近中文字幕国语免费完整| 成人毛片免费网站| 国内精品99亚洲免费高清| 精品无码一区二区三区亚洲桃色| 亚洲人成人无码.www石榴| 国产精品福利片免费看| 99视频全部免费精品全部四虎| 国产精品jizz在线观看免费| 久久亚洲国产欧洲精品一|