《Jersey》关于表征性状态传输（REST）
越来越多的 WEB 服务开始采用了「REST」来实现，究竟「REST」是何方神圣？让我们简单介绍「它」。
首先，「REST」并不是新技术，而是一种设计的默契、风格，而不能算是一种标准。简单的说，「REST」希望针对每一个服务（资源）的管理，透过传统 HTTP 的请求方法（HTTP Request Method）来区分新增、读取、更新、删除（CRUD）。以下做简单说明。
１、「REST」定义一个 URL 是一个资源服务，利用其不同请求方法（Method）来区分对资源的新增、读取、更新及删除的行为。假设我
们想提供一个 WEB 服务，提供对「订单」做管理的服务，用「REST」的原则来定义，大致如下：
| 资源服务 | GET | POST | PUT | DELETE |
| http://www.example/order/ | 读取订单资料 | 建立一组新的订单 | 更新一组指定订单 | 删除一组指定订单 |
２、符合上述「REST」设计风格的 WEB API ，可以称它为「RESTful API」。
３、「RESTful API」接收及返回的的媒体资料类型，可以是 Text、JSON、XML、SOAP 等各种型式。近年来 JSON 格式因较轻量，
越来越多的「RESTful API」以 JSON 为主要的媒体资料类型。
４、「REST」的优点：无状态性使其相依性小、更高效的快取机制增加反应速度、长期的相容性高。
综合上述，「REST」是不是像 2006 年左右「AJAX」般新瓶装旧酒的态势呢？还是说软体设计也开始吹起「回归纯粹、化繁为简」的复古风呢？
