一个好的RESTfulAPI，具备特征
一个好的RESTfulAPI，应该具备以下特征：这个API应该是对浏览器友好的，能够很好地融入Web，而不是与Web格格不入。1.浏览器是最常见和最通用的REST客户端。好的RESTfulAPI应该能够使用浏览器HTML完成所有的测试（不需要使用编程语言）。这样的API还可以很方便地使用各种自动化的Web功能测试、性能测试工具来做测试。Web前端应用（基于浏览器的RIA应用、移动App等等）也可以很方便地将多个RESTfulAPI的功能组合起来，建造Mashup类的应用。这个API中所包含的资源和对于资源的操作，应该是直观和容易理解的，并且符合HTTP协议的要求。REST开发又被称作“面向资源的开发”，这说明对于资源的抽象，是设计RESTfulAPI的核心内容。RESTfulAPI建模的过程与面向对象建模类似，是以名词为核心的。这些名词就是资源，任何可命名的抽象概念都可以定义为一个资源。而HTTP协议并不是一种传输协议，它实际提供了一个操作资源的统一接口。对于资源的任何操作，都应该映射到HTTP的几个有限的方法（常用的有GET/POST/PUT/DELETE四个方法，还有不常用的PATCH/HEAD/OPTIONS方法）上面。所以RESTfulAPI建模的过程，可以看作是具有统一接口约束的面向对象建模过程。按照HTTP协议的规定，GET方法是安全且幂等的，POST方法是既不安全也不幂等的（可以用来作为所有写操作的通配方法），PUT、DELETE方法都是不安全但幂等的。将对资源的操作合理映射到这四个方法上面，既不过度使用某个方法（例如过度使用GET方法或POST方法），也不添加过多的操作以至于HTTP的四个方法不够用。2.如果发现资源上的操作过多，以至于HTTP的方法不够用，应该考虑设计出更多的资源。设计出更多资源（以及相应的URI）对于RESTfulAPI来说并没有什么害处。这个API应该是松耦合的。RESTfulAPI的设计包括了三个循序渐进、由低到高的层次：资源抽象、统一接口、超文本驱动。正是这三个层次确保了RESTfulAPI的松耦合性。3.当设计面向互联网的API时，松耦合变成了一种“必须有”的强需求。紧耦合的API非常脆弱，一旦公布出去，服务器端和客户端都无法持续进化。尤其是服务器端，公布出去的接口根本不敢改，改了之后，几乎所有客户端应用立即无法正常工作。REST这种架构风格就是紧耦合API的解毒剂，这个话题可以谈的很深，这里就不展开了。感兴趣的读者可以参考《REST实战》。这个API中所使用的表述格式应该是常见的通用格式在RESTfulAPI中，对于资源的操作，是通过在服务器端-客户端之间传递资源的表述来间接完成的。资源的表述可以有很多种格式，并且在响应和请求中的资源表述格式也会有所不同。GET/POST响应中的资源表述格式，常见的有HTML、XML、JSON；POST/PUT请求中的资源表述格式，常见的有标准的HTML表单参数、XML、JSON。4.这些常见表述格式，处理起来非常容易，有大量的框架和库提供支持。所以除非有很合理的要求，通常不需要使用自定义的私有格式。使用HTTP响应状态代码来表达各种出错情况HTTP响应状态代码，是HTTP协议这个统一接口中用来表达出错情况的标准机制。响应状态代码分成两部分：statuscode和reasonphase。两部分都是可定制的，也可以使用标准的statuscode，只定制reasonphase。5.如果一个所谓的“RESTfulAPI”对于任何请求都返回200OK响应，在响应的消息体中返回出错情况信息，这种做法显然不符合“确保操作语义的可见性”这个REST架构风格的基本要求。这个API应该对于HTTP缓存是友好的6.充分利用好HTTP缓存是RESTfulAPI可伸缩性的根本。HTTP协议是一个分层的架构，从两端的useragent到originserver之间，可以插入很多中间组件。而在整个HTTP通信链条的很多位置，都可以设置缓存。HTTP协议内建有很好的缓存机制，可以分成过期模型和验证模型两套缓存机制。如果API设计者完全没有考虑过如何利用HTTP缓存，那么这个API的可伸缩性会有很多问题。
什么是REST以及 RESTful?
image image 本文由 黑壳博客 转载 本文来源 什么是REST以及 RESTful?？ imagepng imagepng 自从Roy Fielding博士在2000年他的博士论文中提出 REST （Representational State Transfer）风格的软件架构模式后，REST就基本上迅速取代了复杂而笨重的SOAP，成为Web API的标准了。 什么是Web API呢？ 如果我们想要获取某个电商网站的某个商品，输入 http://localhost:9999/products/123 ，就可以看到id为123的商品页面，但这个结果是HTML页面，它同时混合包含了Product的数据和Product的展示两个部分。对于用户来说，阅读起来没有问题，但是，如果机器读取，就很难从HTML中解析出Product的数据。 如果一个URL返回的不是HTML，而是机器能直接解析的数据，这个URL就可以看成是一个Web API。比如，读取 http://localhost:9999/api/products/123 ，如果能直接返回Product的数据，那么机器就可以直接读取。 REST就是一种设计API的模式。最常用的数据格式是JSON。由于JSON能直接被JavaScript读取，所以，以JSON格式编写的REST风格的API具有简单、易读、易用的特点。 编写API有什么好处呢？由于API就是把Web App的功能全部封装了，所以，通过API操作数据，可以极大地把前端和后端的代码隔离，使得后端代码易于测试，前端代码编写更简单。 此外，如果我们把前端页面看作是一种用于展示的客户端，那么API就是为客户端提供数据、操作数据的接口。这种设计可以获得极高的扩展性。例如，当用户需要在手机上购买商品时，只需要开发针对iOS和Android的两个客户端，通过客户端访问API，就可以完成通过浏览器页面提供的功能，而后端代码基本无需改动。 当一个Web应用以API的形式对外提供功能时，整个应用的结构就扩展为： REST-arch REST-arch 把网页视为一种客户端，是REST架构可扩展的一个关键。 ** 网络上的所有事物都被抽象为资源** ** 每个资源都有一个唯一的资源标识符** ** 同一个资源具有多种表现形式(xml,json等)** ** 对资源的各种操作不会改变资源标识符** ** 所有的操作都是无状态的** ** 符合REST原则的架构方式即可称为RESTful** REST主要对以下两方面进行了规范 -定位资源的URL风格，例如 http://bhusk.com/admin/1234 http://bhusk.com/admin/1234/10/11 -如何对资源操作 采用HTTP协议规定的GET、POST、PUT、DELETE动作处理资源的增删该查操作 image image 对应的中文是rest式的;Restful web service是一种常见的rest的应用,是遵守了rest风格的web服务;rest式的web服务是一种ROA(The Resource-Oriented Architecture)(面向资源的架构). 符合REST约束风格和原则的应用程序或设计就是RESTful. - Spring MVC 对 RESTful应用提供了以下支持 - 利用@RequestMapping 指定要处理请求的URI模板和HTTP请求的动作类型 - 利用@PathVariable讲URI请求模板中的变量映射到处理方法参数上 - 利用Ajax,在客户端发出PUT、DELETE动作的请求 ** 可以采用Ajax方式发送PUT和DELETE请求** 采用RESTful架构后，需要将web.xml中控制器拦截的请求设置为/，这样会将css,js等静态资源进行拦截，发送404错误。 解决方法： 本篇文章参考了一部分 http://t.cn/RuZZUK3 ， http://t.cn/RKO0YPr 程序员是个辛苦的职业 请善待你们身边的每一位程序员~ 欢迎在评论写下你的程序员趣事，程序员不是一个死板的职业~~ 欢迎扫描二维码加入我们的小组织 ，大家都叫我壳叔，很期待你的到来。 黑壳网交流群 Q 群: 200408242 11a84075a304ac57f6d37323512fd24cde9836350b9d80148b282eeaa188b196c2358d4ffd7006cbpng 11a84075a304ac57f6d37323512fd24cde9836350b9d80148b282eeaa188b196c2358d4ffd7006cbpng
