webservice和restful,webservice是什么意思

webservice和restful,webservice是什么意思详细介绍

本文目录一览： WebService、Restful、Http、Socket

1、 WebService到底是什么？

2、 Web service是什么？

3、 什么是WEBService，实现WEBService有哪些框架，为什么WEBService经常被认为太重了，只有银行和大型国企才会使用的更多有一些？

4、 理解RESTful架构

5、 WebService入门介绍

webservice和restful的区别

REST是一种架构风格，其核心是面向资源，REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。REST提出设计概念和准则为：
1.网络上的所有事物都可以被抽象为资源(resource)
2.每一个资源都有唯一的资源标识(resource identifier)，对资源的操作不会改变这些标识
3.所有的操作都是无状态的
REST简化开发，其架构遵循CRUD原则，该原则告诉我们对于资源(包括网络资源)只需要四种行为：创建，获取，更新和删除就可以完成相关的操作和处理。您可以通过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过 HTTP 规范定义的。其核心操作只有GET,PUT,POST,DELETE。
由于REST强制所有的操作都必须是stateless的，这就没有上下文的约束，如果做分布式，集群都不需要考虑上下文和会话保持的问题。极大的提高系统的可伸缩性。
对于SOAP Webservice和Restful Webservice的选择问题，首先需要理解就是SOAP偏向于面向活动，有严格的规范和标准，包括安全，事务等各个方面的内容，同时SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。而REST强调面向资源，只要我们要操作的对象可以抽象为资源即可以使用REST架构风格。
REST ful 应用问题
是否使用REST就需要考虑资源本身的抽象和识别是否困难，如果本身就是简单的类似增删改查的业务操作，那么抽象资源就比较容易，而对于复杂的业务活动抽象资源并不是一个简单的事情。比如校验用户等级，转账，事务处理等，这些往往并不容易简单的抽象为资源。
其次如果有严格的规范和标准定义要求，而且前期规范标准需要指导多个业务系统集成和开发的时候，SOAP风格由于有清晰的规范标准定义是明显有优势的。我们可以在开始和实现之前就严格定义相关的接口方法和接口传输数据。
简单数据操作，无事务处理，开发和调用简单这些是使用REST架构风格的优势。而对于较为复杂的面向活动的服务，如果我们还是使用REST，很多时候都是仍然是传统的面向活动的思想通过转换工具再转换得到REST服务，这种使用方式是没有意义的。
效率和易用性
SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。
REST被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。同时，在我看来REST还有一个很吸引开发者的就是能够很好的融合当前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml作为数据承载，还有（JSON,RSS,ATOM）等形式，这对很多网站前端开发人员来说就能够很好的mashup各种资源信息
安全性
技术没有好坏，只有是不是合适，一种好的技术和思想被误用了，那么就会得到反效果。REST和SOAP各自都有自己的优点，同时如果在一些场景下如果去改造REST，其实就会走向SOAP（例如安全）。
REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。
同时很重要一点就是不要扭曲了REST现在很多网站都跟风去开发REST风格的接口，其实都是在学其形，不知其心，最后弄得不伦不类，性能上不去，安全又保证不了。
成熟度
SOAP虽然发展到现在已经脱离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的web service都能够较好的互通。
由于没有类似于SOAP的权威性协议作为规范，REST实现的各种协议仅仅只能算是私有协议，当然需要遵循REST的思想，但是这样细节方面有太多没有约束的地方。REST日后的发展所走向规范也会直接影响到这部分的设计是否能够有很好的生命力。
restful是一种架构风格，其核心是面向资源；而webService底层SOAP协议，主要核心是面向活动。
SOAP：简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。
客户端和服务器端的通讯方式
REST 与代理服务器 (Proxy Servers)
一般代理服务器的实现根据 (URI, HTTP Method) 两元组来决定 HTTP 请求的安全合法性。
当发现类似于（http://localhost:8182/v1/users/{username}，DELETE）这样的请求时，予以拒绝。
对于 SOAP，如果我们想借助于既有的代理服务器进行安全控制.
REST 与缓存服务器 (Cache Server)
使用 HTTP 协议的 SOAP，由于其设计原则上并不像 REST 那样强调与 Web 的工作方式相一致，所以，基于 SOAP 应用很难充分发挥 HTTP 本身的缓存能力,图 7. SOAP 与缓存服务器 (Cache Server)
总结：
REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。成熟度SOAP虽然发展到现在已经脱离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的web service都能够较好的互通。

RESTful WebService和web service的区别

一个最简单web服务就一个web页面等待请求与处理。更容易理解的方式是Web
Service可以把一个应用变成一个基本WEB方式的请求与处理的应用。常见的两种
Web Service处理方式为：
a. 基于WSDL/SOAP的方式
b. Rest方式
方式a是比较正统的，客户端调用必须先取得WSDL文件，然后生成调用的API才可
以使用。它不是我要说的重点，基本调用流程如下：
方式b是Rest方式，Rest的Web Service的设计原则是基于CRUD，其支持四种操作分
别为：
GET – 获取信息/请求信息内容，绝大多数浏览器获取信息时使用该方式。
POST – 增加信息内容，显示以前的信息内容，可以看作是insert操作
PUT – 更新信息内容，相当与update
DELETE – 删除信息内容可以看作是delete
Rest方式更加简单便捷，如果从设计原则上看HTTP协议本身已经是最Restful风格的
协议了HTTP协议很好的支持了CRUD的操作。正是因为如此，WEB2.0以来, 基于
Restful的Web Service越来越多的成为首选。
二：认识RestfulStyle
Rest的全称是可表述状态迁移(RepresentationalState Transfer), 可能从字面看有点奇怪
HTTP协议本身无状态协议，其保持连接通过设置请求头字段Connection: keep-alive与
设置过期时间来同时控制。其实Rest方式的WebService也是无状态的这样做的好处最少
有以下两个：
1. 更好的负载平衡，减轻服务器端负担
2. 更快的客户端响应，减少不必要的状态检查。
Restful 风格的兴起，要感谢互联网巨头Google,Facebook等他们提供大量基于Restful
风格的web服务，从谷歌地图到天气预报到翻译，国内的互联网巨头腾讯，新浪微博也
发布自己的web服务，吸引更多的开发者加入他们的阵营。Rest除了满足基本的CRUD
设计原则之外，还要遵循如下约定：
1. 资源操作可以通过描述来实现即Representation
2. 消息本身是无状态与自我描述(传输支持XML与JSON)
3. 可以发送与接受多个Representation
Rest风格(Restful Style)架构原则：
1. 客户服务器方式
2. 无状态协议传输
3. 支持缓存
4. 统一接口定义
5. 分层系统设计
这样发布了Rest的Web服务API其改变不会影响到客户端程序与实现。如果你的系统
不能适用Rest风格的架构怎么办，重新设计一个新的架构，扩展Rest风格架构。但是
这个世界上绝大数的系统与应用要做的事情就是CRUD。
三. Rest与HTTP
上面已经提到过HTTP协议可能是最Rest风格的协议，而HTTP1.1协议设计的一个原则
就要实现Rest风格。所以毫无疑问HTTP的GET, POST, PUT, DELETE就是最好的证明
但是Rest风格是否可以应用到其它一些协议与系统设计中嘛，答案是肯定的，一个最好
的例子证明就POP3协议, POP3支持Fetch 数据记录，查询记录，更新记录与删除记录
(记录代表email)多么完美的Rest风格协议。
已经存在的HTTP协议应用：
1. 浏览器客户端(你天天上网，不是IE就是Chrome，或者其它浏览器，你懂的)
2. 即时消息通信，MSN/Skype支持
3. 各种内容管理系统
4. 博客系统与微博客户端应用。
5. 你可以来补充/？

restful和webservice的怎么选

您好！一下为个人看法，希望能对您有帮助，满意的麻烦给个采纳，谢谢了！
从基本原理层次上说，REST 样式和 SOAP 样式 Web Service的区别取决于应用程序是面向资源的还是面向活动的。例如，在传统的WebService中，一个获得天气预报的webservice会暴露一个WebMethod：string GetCityWether（string city）。而RESTful WebService暴露的不是方法，而是对象（资源），通过Http GET, PUT, POST 或者 DELETE来对请求的资源进行操作。在 REST 的定义中，一个 Web Service总是使用固定的 URI 向外部世界呈现（或者说暴露）一个资源。可以说这是一种全新的思维模式：使用唯一资源定位地址 URI，加上 HTTP 请求方法从而达到对一个发布于互联网资源的唯一描述和操作。
所以我理解为rest架构定义的webservice实际上定义了一个借口的规范。
REST其实并不是什么协议也不是什么标准，而是将Http协议的设计初衷作了诠释，在Http协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。
REST的思想归结以下有如下几个关键点：
1．面向资源的接口设计
所有的接口设计都是针对资源来设计的，也就很类似于我们的面向对象和面向过程的设计区别，只不过现在将网络上的操作实体都作为资源来看待，同时URI的设计也是体现了对于资源的定位设计。后面会提到有一些网站的API设计说是REST设计，其实是RPC-REST的混合体，并非是REST的思想。
2．抽象操作为基础的CRUD
这点很简单，Http中的get,put,www.hbbz08.com post,delete分别对应了read,update,create,delete四种操作，如果仅仅是作为对于资源的操作，抽象成为这四种已经足够了，但是对于现在的一些复杂的业务服务接口设计，可能这样的抽象未必能够满足。其实这也在后面的几个网站的API设计中暴露了这样的问题，如果要完全按照REST的思想来设计，那么适用的环境将会有限制，而非放之四海皆准的。
3．Http是应用协议而非传输协议
这点在后面各大网站的API分析中有很明显的体现，其实有些网站已经走到了SOAP的老路上，说是REST的理念设计，其实是作了一套私有的SOAP协议，因此称之为REST风格的自定义SOAP协议。
4．无状态，自包含
这点其实不仅仅是对于REST来说的，作为接口设计都需要能够做到这点，也是作为可扩展和高效性的最基本的保证，就算是使用SOAP的WebService也是一样。

SOAP WebService 和 RESTful WebService 的区别和联系

SOAP(Simple
Object
Access
Protocol)简单对象访问协议，是基于HTTP的一种异构系统通信的协议，说白了就是xml文档传输，之所以会有它，就是在于不同语言C,C++,JAVA等语言开发的系统进行通信，是WebService就是基于SOAP协议的，确实是一种比较传统的SOA解决方案。
REST(Rerepresentational
State
Transfer)是外国一位博士提出的一种架构风格，从资源状态转换角度看待资源，但也是基于SOAP协议进行通信。
rest
是一种风格
restful
Webservice
和
soap的区别在于表现形式不一样，如果想深入了解
可以去开开
深入理解Webservice
这本书，restful
Webservice
不只是可以用json
也可以用xml
更可以用html做消息返回，
rest
风格的Webservice
和传统的soap
主要的表现在于
rest是将资源暴露
soap是暴露操作
。具体的流程其实和soap是一样的，但是rest更方便，更轻。

restful api接口规范是什么？

REST（REpresentationStateTransfer）描述了一个架构样式的网络系统，比如web应用程序。
一般依赖于HTTP认证，HTTP认证有几种：basic，digest，token，这些都有标准的实现的开源包需要主要的是这个认证的帐号跟你业务的帐户实际是不一样的。REST属于webService一种，安全是后台服务的安全，因此不需要实际的业务帐号，通常是系统keyStore证书库里的账户。
RESTFUL特点包括：
1、每一个URI代表1种资源。
2、客户端使用GET、POST、PUT、DELETE4个表示操作方式的动词对服务端资源进行操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
3、通过操作资源的表现形式来操作资源。
4、资源的表现形式是XML或者HTML。
5、客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息。

webservice,soap,rest,wsdl,cxf等的关系

Web服务是基于SOAP是SOAP XML必须符合该协议的请求。如果方便的话，让服务器来实现RESTful风格的服务，以便访问可以通过URL来完成，并返回的json
webservice是一种标准，他可以通过soap或rest的方式来实现。
其中SOAP是基于xml的交互，而rest是基于http协议的交互。
wsdl是webservice的描述语言，描述服务是怎么回事，怎么调用。
cxf是rest实现webservice的Apache框架，是对rest进行了封装

webservice是什么意思

webservice意思是：天气预报。
双语例句：
1、Polling, in this context, means using a RESTful webservice to GET updates for each user.
在这个上下文中，轮询意味着使用一种RESTful Web服务来为每个使用者获得（GET）更新。
2、The@ WebService annotation simply makes the interface a Web service interface.
@WebService标注只是使该接口成为Web服务接口。
3、Create a new folder called webservice in the directory Inetpub.
在Inetpub目录中创建名为webservice的新文件夹。
4、Create a Rails application for the Web service by entering C:/ ruby> rails webservice.
输入C：/ruby>rails webservice以创建Web服务的Rails应用程序。
5、The Development of Electric Power Equipment Inviting and Bidding Management Information System based on COM+/ WebService Multi_tier Distributed Architecture.
基于COM+/WebService多层分布式电力设备招投标管理信息系统的开发。

api接口，RPC，WebService分别解决什么问题

您好,很高兴能帮助您 RPC:所谓的远程过程调用 (面向方法) SOA:所谓的面向服务的架构(面向消息) REST:所谓的 Representational state transfer
API只是一个实现方式，很多平台上会有api接口调用，比如聚合数据，这样使用起来非常方便。
Web Service属于架构里的Web服务，RPC属于Web Service的一种使用方式。
Web Service：
从使用方式上，分为RPC，SOAP，REST；
从数据格式上，分为XML，JSON；
其中，RPC和SOAP的使用在减少，Restful架构占到了主导地位；XML格式的使用在减少，json等轻量级格式的使用在增多。
RPC即为远程过程调用，像调用本地服务(方法)一样调用服务器的服务(方法)，实现上有XML-RPC，JSON-RPC，只是传输数据格式的不同，使用方式上类似。

springmvc实现restful service时，怎么样用日志记录每次的请求参数

以前一说到Web Service大家肯定会联想到SOAP，现在提到Web Service大家马上联想到RESTful,因为RESTful Web Service已经深得人心，得到重用，相比笨重的SOAP越来越流行了，那么什么是RESTful Web Service？REST英文全称为Representational State Transfer，翻译为中文即表征状态转移，是一种软件架构风格，REST关键原则为：
为所有“事物”定义ID
将所有事物链接在一起
使用标准方法
资源多重表述
无状态通信
RESTful Web Service 是一个使用HTTP并遵循REST原则的Web服务。它从三个方面资源进行定义：
URI，比如：http://example.com/resources/。
Web Service接受与返回的互联网媒体类型，比如：JSON，XML等。
Web Service在该资源上所支持的一系列请求方法（比如：POST，GET，PUT或DELETE）。

HTTP 请求方法在RESTful Web 服务中的典型应用

资源

GET

PUT

POST

DELETE

一组资源的URI，比如http://example.com/resources/

列出 URI，以及该资源组中每个资源的详细信息（后者可选）。

使用给定的一组资源替换当前整组资源。

在本组资源中创建/追加一个新的资源。该操作往往返回新资源的URL。

删除整组资源。

单个资源的URI，比如http://example.com/resources/142

获取指定的资源的详细信息，格式可以自选一个合适的网络媒体类型（比如：XML、JSON等）

替换/创建指定的资源。并将其追加到相应的资源组中。

把指定的资源当做一个资源组，并在其下创建/追加一个新的元素，使其隶属于当前资源。

删除指定的元素。

二SpringMVC对RESTful Web Service的支持：
1.将URI和HTTP请求方法映射到JAVA处理方法，并将JAVA方法处理结果返回给HTTP请求者（对应资源定义I和III）。
@RequestMapping
这是最重要的一个注解，用于处理HTTP请求地址映射，可用于类或方法上，用于类上时表示类中的所有响应请求的方法都是以该地址作为父路径，在Spring中，一般一个Controller类处理一种资源，所以每个Controller类都会加@RequestMapping注解。
常用属性：
value：指定请求的地址
method：指定请求的method类型， GET、POST、PUT、DELETE等
params：指定request中必须包含某些参数值是，才让该方法处理

1

2

3

4

5

6

7

8

9

10

11

@Controller

@RequestMapping(value = "/contact")

public class ContactController {

final Logger logger = LoggerFactory.getLogger(ContactController.class);

@Autowired

private ContactService contactService;

@RequestMapping(value = "/listdata", method = RequestMethod.GET)

@ResponseBody

public Contacts listData() {

return new Contacts(contactService.findAll());

}

@PathVariable
映射URL路径里面的参数

1

2

3

4

5

@RequestMapping(value = "/{id}", method = RequestMethod.GET)

@ResponseBody

public Contact findContactById(@PathVariable Long id) {

return contactService.findById(id);

}

2.将接收的数据（如JSON格式数据）转换为JAVA对象和将JAVA对象转换为请求格式（如XML）的数据（对应资源定义II）。
@RequestBody
用于读取Request请求的body数据，使用Bean配置中的 HttpMessageConverter 将数据转换为JAVA对象，再把对象绑定到 controller中方法的参数上。

1

2

3

4

5

6

7

8

@RequestMapping(value = "/", method = RequestMethod.POST)

@ResponseBody

public Contact create(@RequestBody Contact contact) {

logger.info("Creating contact: " + contact);

contactService.save(contact);

logger.info("Contact created successfully with info: " + contact);

return contact;

}

@ResponseBody
用于将Controller中方法返回的对象，使用Bean配置中的 HttpMessageConverter 转换为指定格式数据，再写入到Response对象的body数据区。

1

2

3

4

5

@RequestMapping(value = "/listdata", method = RequestMethod.GET)

@ResponseBody

public Contacts listData() {

return new Contacts(contactService.findAll());

}

HttpMessageConverter配置示例：

1

2

3

4

5

6

7

8

9

10

<bean

class="org.springframework.http.converter.xml.MarshallingHttpMessageConverter">

默认情况下Spring已经启用了很多HttpMessageConverter，只要将他们的实现在类路径下即可，无需再配置。
ByteArrayHttpMessageConverter – converts byte arrays
StringHttpMessageConverter – converts Strings
ResourceHttpMessageConverter – converts org.springframework.core.io.Resource for any type of octet stream
SourceHttpMessageConverter – converts javax.xml.transform.Source
FormHttpMessageConverter – converts form data to/from a MultiValueMap

.

Jaxb2RootElementHttpMessageConverter – converts Java objects to/from XML (added only if JAXB2 is present on the classpath)

MappingJackson2HttpMessageConverter – converts JSON (added only if Jackson 2 is present on the classpath)

MappingJacksonHttpMessageConverter – converts JSON (added only if Jackson is present on the classpath)

AtomFeedHttpMessageConverter – converts Atom feeds (added only if Rome is present on the classpath)

RssChannelHttpMessageConverter – converts RSS feeds (added only if Rome is present on the classpath)

Spring做得太贴心了，所以开发者简单配置就搞定RESTful WebService功能，然后就可专注于业务逻辑实现上。