REST服务的最佳用途是什么?

Here 这是迄今为止我在REST与SOAP/RPC辩论中看到的最好的演示。

AtomPub是一个很好的REST实现。Netflix API是最好的商业REST API之一。twitterapi无法满足大多数RESTful约束。

如果您需要有关REST的准确信息,请访问以下位置:

• http://roy.gbiv.com/untangled/
• http://tech.groups.yahoo.com/group/rest-discuss/
• http://www.innoq.com/blog/st/
• http://www.infoq.com/

不要听大供应商的话,他们更感兴趣的是让现有产品符合流行语。

后续行动:

当您支持多个客户端访问单个服务器时,缓存和无状态服务器的好处变得更加明显。服务器-服务器通信通常为1-1,很少有大量服务器与单个服务器通信。

松耦合

剩下的就是松耦合。其思想是,您可以继续改进服务器,而无需更新客户端。如果您正在考虑在服务器a上实现REST服务,该服务将由位于同一房间中的服务器B调用,那么松耦合的好处就会减少。在两台机器上更新一个软件不会让你丧命。

超媒体

超媒体约束是基于当前应用程序状态为用户提供选择。REST接口支持超链接系统的特别探索。服务器通信往往侧重于实现特定任务。e、 g.处理这批数据。根据计划触发这些事件。本质上,没有用户坐在那里决定走哪条路。已经基于参数和条件预先确定了路径。

表演

互操作性

REST建议使用标准媒体类型作为HTTP有效负载。这鼓励人们意外地重复使用所提供的服务。我认为,与针对其他服务器的服务相比,重用客户机应用程序使用的服务的机会要多得多。

在设计REST接口时,我喜欢认为服务的使用者是一个由最终用户直接控制的软件。web浏览器被称为用户代理并非巧合。

SOAP是REST最受欢迎的替代品,我发现了几个很好的链接,描述了它们的区别以及何时使用它们:

• REST vs SOAP Web Services
• When to use REST and when to use SOAP
• RESTful Web Services

它的要点是REST比它的替代品(特别是SOAP)简单得多,当您只需要基本功能(创建/读取/更新/删除)并且您的服务是无状态的时,应该使用REST。

如果您想要一个使用REST的示例应用程序, CouchDB 做除此之外,很多网站都使用它,比如Flickr、del.icio.us、Bloglines和Technorati。

有很多例子。GData和Atom-Pub协议可能是最好的。Twitter似乎也有一个很好的RESTAPI。亚马逊的S3服务也相当“RESTful”。不幸的是,许多声称是RESTful的服务违反了Roy Fielding在其著作中提出的REST的核心原则 dissertation

REST是一种体系结构样式,不是定义的标准或实现中的集合。这使得说什么是REST服务和什么不是REST服务变得更加困难,这就是为什么您经常听到“RESTful”。

有很多REST接口: flickr Google's data APIs 我想到两个大例子。

REST非常适合于简单的数据交互和无状态连接(类似于HTTP本身)。SOAP是一种常见的替代方案,通常用于更复杂的连接。REST现在非常流行,如果您刚刚了解为什么需要数据接口,那么REST是一个很好的起点。设计REST接口容易学习,入门门槛低。

你应该考虑你的客户想要什么!构建一个无人愿意使用的大型SOAP服务将是浪费您的时间。类似地,如果你的潜在用户沉浸在SOAP中,那么也许你应该给他们这样的机会。

如果你不知道你的用户想要什么,想想这个行业的情绪。现在大多数公开公共API的公司都公开RESTAPI。我真的很喜欢Foursquare对他们的记录: https://developer.foursquare.com/overview/

当数据的最终目标是CRUD操作时,REST是有效的,通常在web UI中,通常使用AJAX、Flash、Silverlight之类的体验,当安全性、加密、事务不是问题时,但是如果您的需求包括前面提到的任何类似企业的功能,REST就是有效的(事务、加密、互操作性等)SOAP是解决方案。