RESTful API 设计最佳实践（7）

RESTful API 设计最佳实践（7）

本篇博客将侧重介绍在RESTful API设计中，消息头HEADER和消息体body相关的东西。URL只是RESTful API设计的主要一部分，要实现REST的统一接口，HTTP协议中的其他部分也不可或缺。关于统一接口，可查看我之前的博客。

一、返回新建资源的URL

使用POST新建的资源时，如果创建成功，则返回201状态码，，应该在返回的消息头HEADER的 location 字段中，加上指向新建资源的URL，这是HTTP规范只一（参见rfc2616）。根据实际需要，可以在body中带上一些必要的信息。

也就是说，在RESTful API中，很多情况下，跟状态码+一些标准的header字段信息，就能够很快获知请求处理结果，而不一定非要从body中费力解析出来。但是往往我们会忽略掉这一点，而将所有处理结果信息全部塞到body中，如：

:body {:result :success :id "新资源ID"}

这种方式其实还是RPC设计思维，并且单纯返回一个新资源的ID号也是不正确的（但估计绝大多数人的实现习惯中，都是这样做的）。因为在REST中，资源是用URL定义的，一个资源ID并不能标识资源在服务其中所处的位置。客户端通过post请求新建资源时，它并不知道服务器具体把它新建到哪里了，所以服务器应当返回一个具体的URL给客户端。

二、XML vs JSON vs EDN

1. 格式的对比和选择

下图为谷歌探索中查到的XMLAPI 、JSON API以及EDN使用量的数据（搜索不到EDN数据，因此用clojure代替——用clojure开发的，大多都用edn格式吧，不是很精确）

XML API使用量越来越小，JSON API程上升趋势，clojure的使用量也在增加。如果你的服务没有被XML捆绑，那么可以完全放弃提供XML API了。如果你是clojure和clojurescript的使