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就需要考虑资源本身的抽象和识别是否困难，如果本身就是简单的类似增删改查的业务操作，那么抽象资源就比较容易，而对于复杂的业务活动抽象资源并不是一个简单的事情。比如校验用户等级，转账，事务处理等，这些往往并不容易简单的抽象为资源。

其次如果有严格的规范和标准定义要求，而且前期规范标准需要指导多个业务系统集成和开发的时候，SOAP风格由于有清晰的规范标准定义是明显有优势的。我们可以在开始和实现之前就严格定义相关的接口方法和接口传输数据。

简单数据操作，无事务处理，开发和调用简单这些是使用REST架构风格的优势。而对于较为复杂的面向活动的服务，如果我们还是使用REST，很多时候都是仍然是传统的面向活动的思想通过转换工具再转换得到REST服务，这种使用方式是没有意义的。

正如另外一篇文章里面谈到的，REST核心是url和面向资源，url代替了原来复杂的操作方法。REST允许我们通过url设计系统，就像测试驱动开发使用测试用例设计类接口一样。所有可以被抽象为资源的东西都可以使用RESTful的url，当我们以传统的用SOAP方式实现的一个查询订单服务的时候可以看到，这个服务首先存在输入的查询条件，然后才是输出结果集。那么对于类似场景要使用REST，不可避免的会将传统的SOAP服务拆分为一个HTTP POST操作和一个HTTP GET操作。前面是输入，而后面是输出。

使用REST的关键是如何抽象资源，抽象的越精确，对REST的应用越好。如何进行抽象，面向资源的设计和传统的面向结构和对象设计区别，资源和对象，数据库表之间的差别是另外一个在分析设计时候要考虑的问题。在REST分析设计中如何改变传统的SOAP分析设计思想又是一个重要问题。