rest的使用原则

大部分对REST的介绍是以其正式的定义和背景作为开场的。这里提出一个简要的定义：REST定义了Web的使用标准（这和大多数人的实际使用方式有很大不同），例如>

系统bug，网络问题。
1、系统bug是rest服务软件系统出现了问题导致防火墙通不过，等待官方修复即可。
2、网络问题是自身设备连接的网络出现较大波动，导致rest服务软件防火墙通不过，更换网络重新打开即可。

一个好的RESTfulAPI，应该具备以下特征：

这个API应该是对浏览器友好的，能够很好地融入Web，而不是与Web格格不入。

1浏览器是最常见和最通用的REST客户端。好的RESTfulAPI应该能够使用浏览器HTML完成所有的测试（不需要使用编程语言）。这样的API还可以很方便地使用各种自动化的Web功能测试、性能测试工具来做测试。Web前端应用（基于浏览器的RIA应用、移动App等等）也可以很方便地将多个RESTfulAPI的功能组合起来，建造Mashup类的应用。

这个API中所包含的资源和对于资源的 *** 作，应该是直观和容易理解的，并且符合>

REST开发又被称作“面向资源的开发”，这说明对于资源的抽象，是设计RESTfulAPI的核心内容。RESTfulAPI建模的过程与面向对象建模类似，是以名词为核心的。这些名词就是资源，任何可命名的抽象概念都可以定义为一个资源。而>

按照>

2如果发现资源上的 *** 作过多，以至于>

这个API应该是松耦合的。

RESTfulAPI的设计包括了三个循序渐进、由低到高的层次：资源抽象、统一接口、超文本驱动。正是这三个层次确保了RESTfulAPI的松耦合性。

3当设计面向互联网的API时，松耦合变成了一种“必须有”的强需求。紧耦合的API非常脆弱，一旦公布出去，服务器端和客户端都无法持续进化。尤其是服务器端，公布出去的接口根本不敢改，改了之后，几乎所有客户端应用立即无法正常工作。REST这种架构风格就是紧耦合API的解毒剂，这个话题可以谈的很深，这里就不展开了。感兴趣的读者可以参考《REST实战》。

这个API中所使用的表述格式应该是常见的通用格式

在RESTfulAPI中，对于资源的 *** 作，是通过在服务器端-客户端之间传递资源的表述来间接完成的。资源的表述可以有很多种格式，并且在响应和请求中的资源表述格式也会有所不同。GET/POST响应中的资源表述格式，常见的有HTML、XML、JSON；POST/PUT请求中的资源表述格式，常见的有标准的HTML表单参数、XML、JSON。

4这些常见表述格式，处理起来非常容易，有大量的框架和库提供支持。所以除非有很合理的要求，通常不需要使用自定义的私有格式。

使用>

>

5如果一个所谓的“RESTfulAPI”对于任何请求都返回200OK响应，在响应的消息体中返回出错情况信息，这种做法显然不符合“确保 *** 作语义的可见性”这个REST架构风格的基本要求。

这个API应该对于>

6充分利用好>为了能够在桌面端软件中简单方便的对外提供RestApi接口，参考Java SpringMVC框架使用C#语言编写了一个简易RestApi服务器框架，目前支持：

- 静态页面处理

- GET/POST/PUT/DELETE请求

- 支持返回JSON

- 支持路由方法

- 支持自定义过滤器

- 服务器返回数据支持gzip压缩

- 支持Component变量自动注入

- 支持Component自动扫描

- GET/POST支持查询参数，POST支持body数据

- 注解支持

  - Component

  - WebFilter

  - RequestMapping

  - Autowired

  - RequestBody

  - RequestParam

new RestApplicationServer()run(new RestConfiguration {

    StaticFileConfigurations = new List<StaticFileConfiguration>() {

        new StaticFileConfiguration("/e", "E:\\"),

        new StaticFileConfiguration("/f", "F:\\")

    }

});

// 将 >