❶ RESTful WebService和web service的区别
restful是一种架构风格，其核心是面向资源；而webService底层SOAP协议，主要核心是面向活动。
SOAP：简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。
客户端和服务器端的通讯方式
总结：
REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。成熟度SOAP虽然发展到现在已经脱离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的web service都能够较好的互通。
❷ 什么是RESTful Web Service
其实早在web service概念产生前就有了restful的概念，或者说restful是和Http一起诞生的。
可以参阅 Roy Fielding 的论文“Architectural Styles and the Design of Network-based Software Architectures”， 我本身并没有读过。
Restful的意思是‘宁静的’，你可以理解为‘简约而不简单’，或者‘和谐的’。一个协议只有足够的简约才有扩展性和生命力，复杂的东西往往伴随的是大量bug和规模膨胀后的不可控。
Restful就是Http的本质，仅仅是一个资源URI，和Get，Post，Put，Delete四种操作。一切Web的行为皆源于此。
所以早期的网站，或者说是静态的网站的都是Restful的，如果广义的把浏览器获取web page当做一种web service的话，那么他们都提供了Restful Web Service。
所以Restful并不是个陌生的概念，更不是个新的概念，只不过是一直被忽略了。
一样东西之所以被忽略，因为没有对立面， 或者说没有可比较的东西。世界上的概念都是相对的，有了丑才有美，有了胖才有瘦。
同样当仅仅只有restful的时候，便很少有人真正了解restful的意思。
直到有一天，restful的原则被打破，世界上出现了非restful的web行为，我们可以把它称做‘RPC-style’的web service。
❸ 我怎样写，它接受一个二进制文件RESTful Web服务
fopen(filename,"w+b")例如FILE*fp=fopen("test.dat","wb+")；--详细说明fopen()函数的用法fopen函数用于打开文件,其调用格式为:FILE*fopen(char*filename,*type);fopen()函数中第一个形式参数表示文件名,可以包含路径和文件名两部分。如:"B:TEST.DAT""C:\\TC\\TEST.DAT"注意：如果将路径写成"C:\TC\TEST.DAT"是不正确的,这一点要特别注意。fopen函数用来打开一个文件，其调用的一般形式为：文件指针名=fopen(文件名，使用文件方式)其中，“文件指针名”必须是被说明为FILE类型的指针变量，“文件名”是被打开文件的文件名。“使用文件方式”是指文件的类型和操作要求。“文件名”是字符串常量或字符串数组。例如：FILE*fp；fp=("filea","r");其意义是在当前目录下打开文件filea，只允许进行“读”操作，并使fp指向该文件。又如：FILE*fphzkfphzk=("c:\\hzk16',"rb")其意义是打开C驱动器磁盘的根目录下的文件hzk16，这是一个二进制文件，只允许按二进制方式进行读操作。两个反斜线“\\”中的第一个表示转义字符，第二个表示根目录。使用文件的方式共有12种，下面给出了它们的符号和意义。第二个形式参数表示打开文件的类型。关于文件类型的规定参见下表。表文件操作类型━━━━━━━━━━━━━━━━━━━━━━━━━━━━字符含义————————————————————————————"r"打开文字文件只读"w"创建文字文件只写"a"增补,如果文件不存在则创建一个"r+"打开一个文字文件读/写"w+"创建一个文字文件读/写"a+"打开或创建一个文件增补"b"二进制文件(可以和上面每一项合用)"t"文本文件(默认项)
❹ 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也是一样。
❺ webservice和restful的区别
restful是一种架构风格，其核心是面向资源；而webService底层SOAP协议，主要核心是面向活动。
SOAP：简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。
客户端和服务器端的通讯方式
总结：
REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。
成熟度
SOAP虽然发展到现在已经脱离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的web service都能够较好的互通。
❻ RESTful Web API 具有怎样的特征
Yii框架 Yii是一个基于组件、用于开发大型 Web 应用的 高性能 PHP 框架。Yii 几乎拥有了 所有的特性 ，包括 MVC、DAO/ActiveRecord、I18N/L10N、caching、基于 JQuery 的 AJAX 支持、用户认证和基于角色的访问控制、脚手架、输入验证、部件
❼ 如何实现RESTful Web API的身份验证
最近想拿一个小项目来试水RESTful Web
API，项目只有几个调用，比较简单，但同样需要身份验证，如果是传统的网站的话，那不用说，肯定是用户名+密码在登录页获得登录Token，并把登录
Token记在Cookie和Session中作为身份标识的这种方式，但现在不同了，关键是RESTful，这意味着我们设计出来的这些API是无状态
的（Stateless），下一次的调用请求和这一次的调用请求应该是完全无关的，也就是说，正宗的RESTful Web
API应该是每次调用都应该包含了完整的信息，没错，包括身份信息！
那如何确保安全？传输时给密码做MD5加密？得了吧！这样做只能让你自己感觉“安全”点，其实没什么任何用处，利用现在的技术（有种叫什么Rainbow Table啥的来着？本人外行，不是很懂）很快就能算出明文密码了，而且如何防止挟持和重发攻击？
也许你想到了，SSL，如果你打算采用SSL，请忘记一切自行设计的加密方案，因为SSL已经帮你做好了一切，包括防止监听，防止挟持，防止重发……一切都帮你考虑好了，你大胆地把明文密码写在你的包中就OK了，我向你保证没问题。
但SSL的缺点是服务器端配置相对有点复杂，更关键的就是客户端对此支持可能不好，那你考虑一种自己的加密方法，有木有？我这里提供一种方法，思路来自
于：http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-
authentication/，我只是把上面的内容中整理了一下变成了我的方法。（传说中的剽窃？呵呵）方法描述如下：
假设有一个用户，用户名是guogangj，密码是123456（呃……这也能叫密码？）
他要GET http://test.com/api/orders/
于是把 http://test.com/api/orders/这个URL和一个新生成的GUID拼在一起，再用123456这个密码执行对称加密，生成的密文为XXXXOOOOXXXXOOOO（假设而已）
数据包中带上用户名guogangj和XXXXOOOOXXXXOOOO这个密文，发送给服务器
服务器收到包后，根据guogangj这个用户名到数据库中查找到123456这个密码
服务器使用123456这个密码来解密XXXXOOOOXXXXOOOO这个密文，得到了明文，即http://test.com/api/orders/这个URL和前面由客户端生成的那个GUID
服务器到一个全局的集合中查找这个GUID，看看是否已经存在，如果存在，则验证不通过，如果不存在，就将其放入这个集合中。这是为了避免重发攻击。这个全局的集合会越来越大，所以还要定期清理。
服务器再比对解密出来的URL和用户真实请求的URL是否一致，如果一致，那么认为这是合法用户，验证通过！
这是大致过程，如果数据库里找不到该用户，或者解密错误，都被认为验证不通过。以下是一些改进：
数据库中的密码最好做一下摘要（MD5之类的），客户端对应地也要做一下。
在生成密文的时候可以考虑加入另外一些不希望被明文传输的敏感内容，甚至可以加入IP地址，并在服务器端验证。
并
非每次都要真正去数据库里拿一次用户信息，也许你有更好的办法，比如一个简单的缓存（不过需要处理缓存更新的问题），或者当你的系统大到一定程度的时候，
你考虑使用统一的服务来获取用户信息，这就不是缓存那么简单了，里面的文章很多，我相信现在大规模的门户网站都有自己的一套复杂的机制，所以表明上看
RESTful Web API很“低效”，但这种RESTFul的思路和模式却在实际中有很大的可塑性和威力。
这种方法应该足够安全了！
密码根本没有在网络上传输，密文采用的是非验证的对称加密，没有密钥就无法逆转，URL验证避免了传统的身份挟持攻击（即拦截一个用户的包并冒充此用户来访问其它的资源，即便无法破解用户密码）， 再用GUID来避免了重发攻击，唯一需要担心的是用户泄露了自己的密码。
❽ "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更方便，更轻。