关于 RESTful 的一点思考

RESTful 是什么?

来自《Spring 实战》:

REST 组成:表述性、状态、转移。

REST 是将资源的状态以最合适的形式从服务器转移到客户端。

RESTless

RESTless 是面向行为的,而不是面向资源的。比如:
http://host:port/servletContext/showUser.action?id=123

在这个 URL 里,servletContext 是 servlet 上下文路径;showUser.action 是控制器 URL 模式,其中 show 是动词,是一种行为;id=123 是标识符。

RESTful URL

比如:http://host:port/servletContext/users/123

在这个 URL 里,users 是资源类型(名词),123 是特定的 user。

这个 URL 并不做任何事情,只是标识了一个资源,而对这个资源做什么是由 HTTP 请求的方法决定的。

RESTful URL 的一些特性:

  • 不仅定位资源,还可以唯一标识这个资源;
  • 有层次,从左到右读时,是一个从抽象到具体的过程;
  • 对于服务器端应用,路径是参数化的。

方法 描述 是否安全 是否幂等
GET 从服务器检索资源数据。资源通过请求的 URL 来进行标识
POST 传送数据到服务器上,数据会由监听该请求的 URL 的处理器来进行处理
PUT 按照请求的 URL,放置资源数据到服务器上
DELETE 将请求 URL 标识的资源从服务器上删除
OPTIONS 请求与服务器通信可用的选项
HEAD 类似于 GET,但只会返回头部信息–在响应体中不应该包含内容
TRACE 将请求体的内容返回给客户

企业应用是否适合用 RESTful ?

RESTful 目前给我的印象是,除了让 URL 更具表述性外,没有其他太多好处。

但是 URL 参数化带来的一个主要问题是:访问日志的分析、统计很困难。就算是访问同一个 API 控制器,由于参数值不同,导致访问不同资源的 URL 是不一样的,想通过分析访问日志来查看每个 API 的调用情况就很困难了。

或许可以通过前端的 Web 服务器(比如 Nginx)进行 URL 重写,然后在转发到后端的应用服务器,由应用服务器来记录访问日志。这显然多了一层复杂性,而且每新增一个 API 难道又得去 Web 服务器上新增一条 URL 规则??

在 Spring MVC 里面,抽取 URL 里的参数还需要一个注解,不如请求参数方便。

我觉得:对每个 API 的 URL 进行规范化是很重要的,但不应该引入 URL 参数化。


欢迎关注我的微信公众号: coderbee笔记,可以更及时回复你的讨论。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据