我知道像Facebook这样的网站现在正在使用REST服务,但我想知道其他使用REST的应用程序,如果有特殊情况,使用REST比其他方法更有保证.
Dar*_*ler 36
REST不是关于CRUD数据服务.是的,您可以使用REST来执行类似服务的CRUD,但这就像说正则表达式用于解析电子邮件地址.
这是我在REST与SOAP/RPC辩论中见过的最好的演示文稿.
与处理服务器到服务器的交互相比,REST更倾向于解决分布式客户端/服务器交互.REST是关于在用户面前获取内容以便他们可以选择如何处理它.REST不是要创建基于Http的数据访问层来将应用程序逻辑与其数据存储分离.
Atom Pub是一个很好的REST实现.Netflix API是最好的商业REST api之一.Twitter API失败了大多数RESTful约束.
如果您需要有关REST的准确信息,请访问以下位置:
不要听取大型供应商关于他们更感兴趣的主题,使他们的现有产品符合流行语.
跟进:
我认为REST接口比服务器到服务器交互更适合客户端/服务器交互有几个原因.这只是我的意见,我并不是要声称这个观点是由我以外的任何人持有的!
当您支持许多访问单个服务器的客户端时,缓存和无状态服务器的好处变得更加明显.服务器 - 服务器通信通常为1-1,并且很少有大量服务器与单个服务器通信.
REST就是松散耦合.我们的想法是,您可以继续改进服务器,而无需更新客户端.如果您正在考虑在服务器A上实现REST服务,该服务将由位于同一房间中的服务器B调用,那么松散耦合的好处就会减少.在两台机器上更新一个软件并不会让你失望.
超媒体约束是基于当前应用程序状态为用户提供选择.REST接口支持对超链接系统的即席探索.服务器 - 服务器通信倾向于专注于实现特定任务.例如,处理这批数据.根据计划触发这些事件.本来就没有用户坐在那里决定要遵循哪条路径.已经基于参数和条件预先确定了路径.
在服务器 - 服务器通信场景中,实现最大吞吐量可能至关重要.二进制协议可能比Http更合适.延迟在服务器到服务器类型的通信中可能是至关重要的.在客户端 - 服务器环境中,一端由人驱动,性能要求完全不同,我相信REST约束更适合这种类型的交互.
REST建议使用标准媒体类型作为HTTP有效负载.这鼓励偶然重复使用所提供的服务.我认为有更多机会重新使用供客户端应用程序使用的服务,而不是针对其他服务器的服务.
在设计REST接口时,我喜欢认为服务的使用者是一个受最终用户直接控制的软件.Web浏览器被称为用户代理并非巧合.