转发文章 https://blog.csdn.net/zl834205311/article/details/62231545?ABstrategy=codes_snippets_optimize_v3

WebService两种发布协议--SOAP和REST的区别

 

1、

SOAP是一种具体的通讯协议,REST是一种规范. 

2、

  1. SOAP(Simple Object Access Protocol)简单对象访问协议,是基于HTTP的一种异构系统通信的协议,说白了就是xml文档传输,之所以会有它,就是在于不同语言C,C++,JAVA等语言开发的系统进行通信,是WebService就是基于SOAP协议的,确实是一种比较传统的SOA解决方案。
  2. REST(Rerepresentational State Transfer)是外国一位博士提出的一种架构风格,从资源状态转换角度看待我们的资源(如此简洁,明了),所以外国人是挺牛的,但也是基于SOAP协议进行通信,这是他的论文:
  3. http://jpkc.fudan.edu.cn/picture/article/216/35/4b/22598d594e3d93239700ce79bce1/7ed3ec2a-03c2-49cb-8bf8-5a90ea42f523.pdf
  4. 不是SOAP可以用cxf开发,SOAP只是一个协议标准,你还开发个啥?
  5. 至于WebService开发框架也有很多,比较热门的就cxf, axis, axis2等,具体到apache上一看便知,只是方便我们开发而已,用jdk一样可以开发,只是它们对jdk进行一些封装,跟我们省了事。

3、

rest 是一种风格 restful Webservice 和 soap的区别在于表现形式不一样,如果想深入了解 可以去开开 深入理解Webservice 这本书,restful Webservice 不只是可以用json 也可以用xml 更可以用html做消息返回, rest 风格的Webservice 和传统的soap 主要的表现在于 rest是将资源暴露 soap是暴露操作 ,入门可以看看 http://www.infoq.com/cn/articles/rest-introduction这个网址 cxf也提供restful风格的 Webservice的 具体的流程 其实和soap是一样的 但是rest更方便 更轻,具体的说不上来 东西太多 需要你自己去看了

4、

SOAP比较复杂,基于XML,有对应规范;REST利用HTTP请请求方式GET,POST,PUT约定事务操作。简单的说,SOAP通过传输XML,XML定义了请求和响应的具体数据,要进行的操作等等;而REST则是另一种约定,比如请求/user/1001这个RUL,GET方式返回id为1001的user信息,POST方式则是更新id为1001的user信息,DELETE删除等。

5、

    1. WebService的两种方式SOAP和REST比较 (转)
    2.  
    3. 博客分类: webService
    4. restsoapwebservice
    5. 我的读后感:由于第一次接触WebService,对于很多概念不太理解,尤其是看到各个OpenAPI的不同提供方式时,更加疑惑。如google map api采用了AJAX方式,通过javascript提供API,而淘宝TOP则采用直接的HTTP+XML请求方式,最令我疑惑的是教材上讲的WSDL,UDDI从没有在这些API中出现过。现在知道了WebService原来有两种方式,一是SOAP协议方式,在这种方式下需要WSDL,UDDI等,二是REST方式,这种方式根本不需要WSDL,UDDI等。而且REST方式现在看来是更加流行,更有前途的方式。
    6. 在SOA的基础技术实现方式中WebService占据了很重要的地位,通常我们提到WebService第一想法就是SOAP消息在各种传输协议上交互。近几年REST的思想伴随着SOA逐渐被大家接受,同时各大网站不断开放API提供给开发者,也激起了REST风格WebService的热潮。
    7. 在收到新需求Email之前,我对REST的理解仅仅是通过半懂不懂的看了Fielding的REST博士论文,说实话当时也就是希望了解这么一个新概念,对于其内部的思想只是很肤浅的了解了一下。
    8. ASF的最新需求就是可能需要实现REST风格的WebService集成,因此不得不好好的去看看REST的真正思想含义以及当前各大网站的设计方式。后面所要表述的也是我这个初学者的一些看法和观点,抛砖引玉,希望在我将REST融入到ASF之前能够获得更多的反馈和意见。
    9.  
    10. SOAP
    11. 什么是SOAP,我想不用多说,google一把满眼都是。其实SOAP最早是针对RPC的一种解决方案,简单对象访问协议,很轻量,同时作为应用协议可以基于多种传输协议来传递消息(Http,SMTP等)。但是随着SOAP作为WebService的广泛应用,不断地增加附加的内容,使得现在开发人员觉得SOAP很重,使用门槛很高。在SOAP后续的发展过程中,WS-*一系列协议的制定,增加了SOAP的成熟度,也给SOAP增加了负担。
    12.  
    13. REST
    14. REST其实并不是什么协议也不是什么标准,而是将Http协议的设计初衷作了诠释,在Http协议被广泛利用的今天,越来越多的是将其作为传输协议,而非原先设计者所考虑的应用协议。SOAP类型的WebService就是最好的例子,SOAP消息完全就是将Http协议作为消息承载,以至于对于Http协议中的各种参数(例如编码,错误码等)都置之不顾。其实,最轻量级的应用协议就是Http协议。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查,而互联网上的各种资源就好比数据库中的记录(可能这么比喻不是很好),对于各种资源的操作最后总是能抽象成为这四种基本操作,在定义了定位资源的规则以后,对于资源的操作通过标准的Http协议就可以实现,开发者也会受益于这种轻量级的协议。
    15. 自己理解的将REST的思想归结以下有如下几个关键点:
    16.  
    17. 1.面向资源的接口设计
    18. 所有的接口设计都是针对资源来设计的,也就很类似于我们的面向对象和面向过程的设计区别,只不过现在将网络上的操作实体都作为资源来看待,同时URI的设计也是体现了对于资源的定位设计。后面会提到有一些网站的API设计说是REST设计,其实是RPC-REST的混合体,并非是REST的思想。
    19.  
    20. 2.抽象操作为基础的CRUD
    21. 这点很简单,Http中的get,put,post,delete分别对应了read,update,create,delete四种操作,如果仅仅是作为对于资源的操作,抽象成为这四种已经足够了,但是对于现在的一些复杂的业务服务接口设计,可能这样的抽象未必能够满足。其实这也在后面的几个网站的API设计中暴露了这样的问题,如果要完全按照REST的思想来设计,那么适用的环境将会有限制,而非放之四海皆准的。
    22.  
    23. 3.Http是应用协议而非传输协议
    24. 这点在后面各大网站的API分析中有很明显的体现,其实有些网站已经走到了SOAP的老路上,说是REST的理念设计,其实是作了一套私有的SOAP协议,因此称之为REST风格的自定义SOAP协议。
    25.  
    26. 4.无状态,自包含
    27. 这点其实不仅仅是对于REST来说的,作为接口设计都需要能够做到这点,也是作为可扩展和高效性的最基本的保证,就算是使用SOAP的WebService也是一样。
    28.  
    29.  
    30. REST vs SOAP
    31. 成熟度:
    32. SOAP虽然发展到现在已经脱离了初衷,但是对于异构环境服务发布和调用,以及厂商的支持都已经达到了较为成熟的情况。不同平台,开发语言之间通过SOAP来交互的web service都能够较好的互通(在部分复杂和特殊的参数和返回对象解析上,协议没有作很细致的规定,导致还是需要作部分修正)
    33. REST国外很多大网站都发布了自己的开发API,很多都提供了SOAP和REST两种Web Service,根据调查部分网站的REST风格的使用情况要高于SOAP。但是由于REST只是一种基于Http协议实现资源操作的思想,因此各个网站的REST实现都自有一套,在后面会讲诉各个大网站的REST API的风格。也正是因为这种各自实现的情况,在性能和可用性上会大大高于SOAP发布的web service,但统一通用方面远远不及SOAP。由于这些大网站的SP往往专注于此网站的API开发,因此通用性要求不高。
    34. ASF上考虑发布REST风格的Web Service,可以参考几大网站的设计(兄弟公司的方案就是参考了类似于flickr的设计模式),但是由于没有类似于SOAP的权威性协议作为规范,REST实现的各种协议仅仅只能算是私有协议,当然需要遵循REST的思想,但是这样细节方面有太多没有约束的地方。REST日后的发展所走向规范也会直接影响到这部分的设计是否能够有很好的生命力。
    35. 总的来说SOAP在成熟度上优于REST。
    36.  
    37. 效率和易用性:
    38. SOAP协议对于消息体和消息头都有定义,同时消息头的可扩展性为各种互联网的标准提供了扩展的基础,WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容,导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。
    39. REST被人们的重视,其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计,同时也最大限度的利用了Http最初的应用协议设计理念。同时,在我看来REST还有一个很吸引开发者的就是能够很好的融合当前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式,除了传统的xml作为数据承载,还有(JSON,RSS,ATOM)等形式,这对很多网站前端开发人员来说就能够很好的mashup各种资源信息。
    40. 因此在效率和易用性上来说,REST更胜一筹。
    41.  
    42. 安全性:
    43. 这点其实可以放入到成熟度中,不过在当前的互联网应用和平台开发设计过程中,安全已经被提到了很高的高度,特别是作为外部接口给第三方调用,安全性可能会高过业务逻辑本身。
    44. SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的,当前已经得到了各个厂商的支持,.net ,php ,java 都已经对其有了很好的支持(虽然在一些细节上还是有不兼容的问题,但是互通基本上是可以的)。
    45. REST没有任何规范对于安全方面作说明,同时现在开放REST风格API的网站主要分成两种,一种是自定义了安全信息封装在消息中(其实这和SOAP没有什么区别),另外一种就是靠硬件SSL来保障,但是这只能够保证点到点的安全,如果是需要多点传输的话SSL就无能为力了。安全这块其实也是一个很大的问题,今年在BEA峰会上看到有演示采用SAML2实现的网站间SSO,其实是直接采用了XML-Security和XML-Signature,效率看起来也不是很高。未来REST规范化和通用化过程中的安全是否也会采用这两种规范,是未知的,但是加入的越多,REST失去它高效性的优势越多。
    46.  
    47. 应用设计与改造:
    48. 我们的系统要么就是已经有了那些需要被发布出去的服务,要么就是刚刚设计好的服务,但是开发人员的传统设计思想让REST的形式被接受还需要一点时间。同时在资源型数据服务接口设计上来说按照REST的思想来设计相对来说要容易一些,而对于一些复杂的服务接口来说,可能强要去按照REST的风格来设计会有些牵强。这一点其实可以看看各大网站的接口就可以知道,很多网站还要传入function的名称作为参数,这就明显已经违背了REST本身的设计思路。
    49. 而SOAP本身就是面向RPC来设计的,开发人员十分容易接受,所以不存在什么适应的过程。
    50.  
    51. 总的来说,其实还是一个老观念,适合的才是最好的
    52. 技术没有好坏,只有是不是合适,一种好的技术和思想被误用了,那么就会得到反效果。REST和SOAP各自都有自己的优点,同时如果在一些场景下如果去改造REST,其实就会走向SOAP(例如安全)。
    53. REST对于资源型服务接口来说很合适,同时特别适合对于效率要求很高,但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的,对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义,关键还是看应用场景。
    54. 同时很重要一点就是不要扭曲了REST现在很多网站都跟风去开发REST风格的接口,其实都是在学其形,不知其心,最后弄得不伦不类,性能上不去,安全又保证不了,徒有一个看似象摸象样的皮囊。
    55.  
    56. REST设计的几种形式
    57. 参看了几个大型网站的REST风格的API设计,这里做一下大致的说明:
    58.  
    59. FaceBook:
    60.  
    61. 请求消息:
    62. 在URI设计上采取了类似于REST的风格。例如对于friends的获取,就定义为friends.get,前面部分作为资源定义,后面是具体的操作,其他的API也是类似,资源+操作,因此就算使用http的get方法都可能作了update的操作,其实已经违背了REST的思想,但是说到,其实那么复杂的业务接口设计下,要通过RUCD来抽象所有的接口基本是不实际的。在URI定义好以后,还有详细的参数定义,包括类型以及是否必选。
    63.  
    64. 响应消息:
    65. 有多种方式,XML,JSON。XML有XSD作为参考。有点类似于没有Head的SOAP,只不过这里将原来可以定义在WSDL中的XSD抽取出来了。
    66.  
    67. Flickr:
    68. 请求消息:
    69. http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value
    70. 这里就可以很明显看出它所定制的REST请求其实和RPC没有什么太大的区别。
    71.  
    72. 消息返回:
    73. 正确处理返回
    74. <?xml version="1.0" encoding="utf-8" ?>
    75. <rsp stat="ok">
    76. [xml-payload-here]
    77. </rsp>
    78. 错误处理返回
    79. <?xml version="1.0" encoding="utf-8" ?>
    80. <rsp stat="fail">
    81. <err code="[error-code]" msg="[error-message]" />
    82. </rsp>
    83. 根据返回可以看出已经违背了REST的思想,还是把Http协议作为传输承载协议,并没有真正意义上使用Http协议作为资源访问和操作协议。
    84. 总的来说,只是形式上去模仿REST,自己搞了一套私有协议。
    85.  
    86. Ebay:
    87. 请求消息:
    88. 采用xml作为承载,类似于SOAP,不过去除SOAP消息的封装和包头,同时在请求中附加了认证和警告级别等附加信息。
    89. 消息返回:
    90. 类似于SOAP消息,不过删除了SOAP的封装和包头,同时在返回结构中增加了消息处理结果以及版本等附加信息。
    91. 这个很类似于当前Axis2框架的做法,将SOAP精简,同时根据自身需求丰富了安全,事务等协议内容。
    92.  
    93. Yahoo Maps:
    94. 请求消息:
    95.  
    96. 采用REST推荐的方式,URI+Parameters。
    97. 返回消息:
    98. <?xml version="1.0" encoding="UTF-8"?>
    99. <ResultSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    100. xmlns="urn:yahoo:maps"
    101. xsi:schemaLocation="urn:yahoo:maps http://local.yahooapis.com/MapsService/V1/GeocodeResponse.xsd">
    102. <Result precision="address">
    103. <Latitude>37.416384</Latitude>
    104. <Longitude>-122.024853</Longitude>
    105. <Address>701 FIRST AVE</Address>
    106. <City>SUNNYVALE</City>
    107. <State>CA</State>
    108. <Zip>94089-1019</Zip>
    109. <Country>US</Country>
    110. </Result>
    111. </ResultSet>
    112. SOAP的精简xml返回,其他信息,例如出错码等信息由Http协议头来承载。
    113.  
    114. YouTube:
    115. 请求消息:
    116. 可以看到对于资源操作的URI定义也是参数的一部分。
    117. 返回消息:
    118. <?xml version="1.0" encoding="utf-8"?>
    119. <ut_response status="ok">
    120. <user_profile>
    121. <first_name>YouTube</first_name>
    122. <last_name>User</last_name>
    123. <about_me>YouTube rocks!!</about_me>
    124. <age>30</age>
    125. <video_upload_count>7</video_upload_count>
    126. </user_profile>
    127. </ut_response>
    128. 自定义的类SOAP消息。
    129.  
    130. Amazon:
    131. 请求消息:
    132. https://Amazon FPS web service end point/?AWSAccessKeyId=Your AWSAccessKeyId
    133. &Timestamp=[Current timestamp] &Signature=[Signature calculated from hash of Action and Timestamp]
    134. &SignatureVersion=[Signature calculated from hash of Action and Timestamp]
    135. &Version=[Version of the WSDL specified in YYYY-MM-DD format] &Action=[Name of the API]
    136. ¶meter1=[Value of the API parameter1] ¶meter2=[Value of the API parameter2]
    137. &...[API parameters and their values]
    138. 返回消息:
    139. 类似于SOAP的自有协议,消息体中包含了消息状态等附加信息。
    140.  
    141. 总结:
    142. 看了上面那么多网站的设计,总结一下主要有这么几种设计方式。
    143.  
    144. 请求消息设计:
    145. 1. 基本符合REST标准方式:资源URI定义(资源.操作)+参数。这类设计如果滥用get去处理其他类型的操作,那么和2无异。
    146. 2. REST风格非REST思想:资源URI定义+参数(包含操作方法名)。其实就是RPC的REST跟风。
    147. 3. 类似于SOAP消息,自定义协议,以xml作为承载。(可扩展,例如鉴权,访问控制等),不过那就好比自己定义了一套SOAP和SOAP extends。大型的有实力的网站有的采取此种做法。
    148.  
    149. 响应消息设计:
    150. 1. REST标准方式,将Resource State传输返回给客户端,Http消息作为应用协议而非传输协议
    151. 2. 以XML作为消息承载体,Http作为消息传输协议,处理状态自包含。
    152. 3. 自定义消息格式,类似于SOAP,提供可扩展部分。
    153.  
    154. 作为遵循REST的理念来看我的选择是响应1和请求1的设计。
    155.  
    156.  
    157. REST和ASF的集成
    158. ASF要集成REST就现在来看有两种比较合适的方法。
    159. 一.就是采用Axis2的REST实现,这种方式的好处就是开发周期短,容易集成,但是请求和响应的格式无法改变,资源URI设计受限,Axis2的REST其实就是将SOAP消息精简,请求的时候删除了SOAP的头,响应的时候仅仅返回资源信息,如果提供xsd就可以被各种客户端所解析。并非真正的REST。
    160. 二.就是采用Restlet开源框架,将Restlet开源框架集成到ASF中,由于Restlet本身就是可内嵌的应用框架,因此集成不成问题,同时Restlet框架只是API结构框架,因此实现和定义完全分开,集成Restlet以后可以自己实现其中的解析引擎也可以采用默认提供的引擎,同时对于内嵌Jetty等多种开源项目的支持,将更多优势融入到了Rest中。看了一下国内也有很多朋友已经关注Restlet开源项目,看了它的架构设计,个人觉得还是比较灵活和紧凑的。
    161.  
    162. 题外话
    163. 在写这篇文章以前写了一篇调研报告群发给各个架构师们参考,期待反馈。下午正好和我们的首席架构师聊了一会儿。其实我和他的感觉是一样的,REST是否真的在我们现有的服务框架中需要集成,理解了REST的思想再去看应用场景,那么可以发现如果要完全遵循REST的设计理念来设计接口的话,那么强要去改变现有已经存在的或者还未开发的接口就会落入为了技术而技术,为了潮流而跟风的近地。当然并不否认REST的好,其实我们兄弟公司的一些业务场景有部分的接口十分合适这类设计,面向资源,高效,简洁,易用都能够体现出它的价值。我们将会和我们的兄弟公司合作,也会参考他们的设计理念,在参考当前各个网站的实现情况下,部分的采用这类形式的发布,提供给第三方的ISV,无疑是我现在把REST融入到ASF中最好的理由。
    164. 有了需求去做才不会陷入为了技术而技术,毕竟技术是由商业价值驱动的,同样社会上充斥着各种技术的鼓吹,如果稍不留神就会陷入跟风的潮流中。

转 WebService两种发布协议--SOAP和REST的区别的更多相关文章

  1. WebService发布协议--SOAP和REST的区别

    HTTP是标准超文本传输协议.使用对参数进行编码并将参数作为键值对传递,还使用关联的请求语义.每个协议都包含一系列HTTP请求标头及其他一些信息,定义客户端向服务器请求哪些内容,服务器用一系列HTTP ...

  2. Docker + .NET Core(三)-两种发布方式

    原文:Docker + .NET Core(三)-两种发布方式 第一种,自己手写dockerfile发布,上传至hubDocker 正常发布到文件夹中,发布文件上传至linux机器上.如 /www/a ...

  3. SAML和OAuth2这两种SSO协议的区别

    目录 简介 SAML SAML的缺点 OAuth2 OAuth2的缺点 两者的对比 CAS简介 简介 SSO是单点登录的简称,常用的SSO的协议有两种,分别是SAML和OAuth2.本文将会介绍两种协 ...

  4. eclipse中的两种Jre 及 Jre与Jdk的区别

    分类: ——————————区分eclipse中的两种Jre———————- (Eclipse也是一个普通的Java程序,因此必须有一个JRE做为运行环境.如果你的机器上没有安装任何JRE(或者JDK ...

  5. js两种定义函数、继承方式及区别

    一:js两种定义函数的方式及区别 1:函数声明: function sayA() { alert("i am A"); } 2:函数表达式: var sayB = function ...

  6. js中两种定时器,setTimeout和setInterval的区别

    setTimeout只在指定时间后执行一次,代码如下:   <script>   //定时器 异步运行   function hello(){   alert("hello&qu ...

  7. 并发编程 - 线程 - 1.开启线程的两种方式/2.进程与线程的区别/3.Thread对象的其他属性或方法/4.守护线程

    1.开启线程的两种方式: 进程,线程: 进程只是用来把资源集中到一起(进程只是一个资源单位,或者说资源集合)而线程才是cpu上的执行单位) 1.同一个进程内的多个线程共享该进程内的地址资源 2.创建线 ...

  8. VUE的两种跳转push和replace对比区别

    router.push(location) 在vue.js中想要跳转到不同的 URL,需要使用 router.push 方法. 这个方法会向 history 栈添加一个新的记录,当用户点击浏览器后退按 ...

  9. 史上最全的CSS hack方式一览 jQuery 图片轮播的代码分离 JQuery中的动画 C#中Trim()、TrimStart()、TrimEnd()的用法 marquee 标签的使用详情 js鼠标事件 js添加遮罩层 页面上通过地址栏传值时出现乱码的两种解决方法 ref和out的区别在c#中 总结

    史上最全的CSS hack方式一览 2013年09月28日 15:57:08 阅读数:175473 做前端多年,虽然不是经常需要hack,但是我们经常会遇到各浏览器表现不一致的情况.基于此,某些情况我 ...

随机推荐

  1. symbol lookup error: /lib64/libpango-1.0.so.0: undefined symbol: g_log_structured_standard 错误

    通过更新glib2包修复.(yum update glib2)即可 拿走不谢,我也找得好辛苦!!!

  2. python进阶01 面向对象、类、实例、属性封装、实例方法

    python进阶01 面向对象.类.实例.属性封装.实例方法 一.面向对象 1.什么是对象 #一切皆对象,可以简单地将“对象”理解为“某个东西” #“对象”之所以称之为对象,是因为它具有属于它自己的“ ...

  3. BZOJ 1123 && Luogu P3469 [POI2008]BLO-Blockade 割点+乘法原理

    想了半天式子...最后在邓大师的帮助下想出此题....QWQ我还是太菜了 对于一个非割点,ans+=2*(n-1); 对于一个割点,ans+= #include<cstdio> #incl ...

  4. POJ3694 Network 边双缩点+LCA+并查集

    辣鸡错误:把dfs和ldfs搞混...QAQ 题意:给定一个无向图,然后查询q次,求每次查询就在图上增加一条边,求剩余割边的个数. 先把边双缩点,然后预处理出LCA的倍增数组: 然后加边时,从u往上跳 ...

  5. poj1185-炮兵阵地(状态压缩dp)

    炮兵阵地 Time Limit: 2000MS   Memory Limit: 65536K Total Submissions: 25647   Accepted: 9892 Description ...

  6. github 新建一个分支

    我能说今天在github上新建分支的时候懵逼了半天吗..为了下次不再懵逼,还是在这里记录一下吧.. 进入你的项目---code---Branch----点击那个倒三角-----你会发现一个输入框(这是 ...

  7. 1137 - Sin your life sin公式 + 枚举

    http://www.ifrog.cc/acm/problem/1137 和差化积公式, 变成2 * sin((x + y) / 2) * cos((x - y) / 2) + sin(n - (x ...

  8. (转)nginx应用总结(1)--基础认识和应用参数优化配置

    在linux系统下使用nginx作为web应用服务,用来提升网站访问速度的经验已五年多了,今天在此对nginx的使用做一简单总结. 一.nginx服务简介Nginx是一个高性能的HTTP和反向代理服务 ...

  9. Eclipse Debug模式和断点调试

    1行号上双击,打断点:再双击,取消断点.一般想调试哪一句代码,就在哪一句和下一句打上断点. 2在要执行的class文件上(有main方法的),右键--Debug As 然后程序正常走,当走到断点时,会 ...

  10. 使用Calendar来获取当前日期和时间

    1 package com.java.test; 2 3 import java.text.SimpleDateFormat; 4 import java.util.Calendar; 5 6 pub ...