restful 主要围绕着资源来进行讨论
0.Restful 的一次资源操作过程
指定一个 URI，并使用对应的 资源操作 方法，发起资源的请求，请求对于 资源的属性描述 ，可以在 Accept 中描述；然后在响应结果中，body 仅仅是数据的结果，关于数据的其他描述性信息，则放在 Headers 里面去解释，而响应的状态由 http的响应状态码 去表示。
这样，一次资源的操作就结束了。
然后按照这样的流程来说，主要的问题就是其中各个步骤的设计方式了。
1.URI 的设计
在 URL 设计中，最好的状态就是，具有自描述性，在形式上给人以一种直觉上的关联，该资源是属于什么类型的资源，以及该资源的是什么的描述的一个路由， 让人们从路由上就能知道该资源是什么。
注：不能有动词出现。
设计原则（个人推荐）：类似一个物品分类
/<产品类型:type-of-product>/<产品：product-name>/<产品的一部分：something-belong-to-product>/...
# example
URI: /animals/cat/eyes
2.资源操作的设计
2.1.操作方法
资源的操作主要就是 GET、POST、PUT、DELETE
划分的功能就是对应的 查询、更新、新增、删除。
2.2.使用习惯
参数传输方式，理论上应该是：
GET：args
POST：form/json
PUT：form/json
DELETE：args
个人经验：form和json的方式来说，数据的数量少的时候可以考虑 form，太多的时候，可以考虑 json 的方式。
3.请求资源属性的设计
请求资源的时候，有时候我们传输一些和资源本身没有直接关系的信息，如果这些信息也放在 BODY 的时候，就会影响到参数的可读性，所以建议是都放在 Headers 里面，这样好看些。
Accept: version=1.0;format=json
关于数据属性（实际上就是同一个资源表现形式）来说，使用 Accept 会更好一些，其他的信息可以自行设计，但是不要放在 BODY 里面。
4.响应结果和描述信息的设计
响应结果里面，对于需要得到的数据结果是通过返回信息来提供的，但是有一个和资源没有直接关系的信息，则需要放在响应头里面去。
# response headers
r_status:true
r_scale: 18*18
例如：我们在请求一个图片的链接的时候，返回的信息应该是该图片的链接信息，比如其获取资源的结果状态啊，该资源的规格等等都应该放在响应头里面去。
5.Http 状态码的规划
与业务无关的状态信息，尽量以 HTTP 状态的方式呈现。比如 404，或者是501之类的，其请求根本就没进入到业务层，所以使用 HTTP 的方式会更好一些。而涉及到业务的状态来说，就可以放在响应头里面。
6.实战演练
略。。。
网友评论