RestfulApi 学习笔记——简单介绍（一）

前言

什么是restapi？

直接看：http://www.ruanyifeng.com/blog/2014/05/restful_api.html

阮一峰的blog，即可明白，下面是一些例子，增强理解。

正文

例子一资源链是箱子

比如说我们要得到某个用户，我们可能这样写:api/getusers

这样就不符合了，因为操作动作让请求方式替代。

比如说get 请求就表示是获取users，那么就不需要写get，那么可以这样写:api/getusers 然后get请求。

这个怎么说呢？也就是说把资源链当做资源链，而不是语义，说简单点就是资源链指向的是某个资源，而不是某个操作。

那么如果获取方式不同怎么写呢？比如说查询按照某个字段从小到大排序，那么应该如何写呢？我们需要明白查询从小到大排序是条件，而不是动作。

那么可以作为参数来传递api/getusers?orderby='xxx'

例子二给箱子取一个好的名字

api/users 那么你能写成api/u,因为这样不具备语义化

例子三不要给箱子定义多个名字

比如说我们获取到多个用户，那么我就使用api/users，然后我获取某个用户我就去获取api/user/1。

这样其实是没有必要的，api/users 表示的就是users 这个资源箱。使用api/user/1 从新给箱子又改了一个名字，我觉得这样难以维护，

而且这样做，不能体现这是一条资源链，因为user 并不能表示这个资源箱的名字，而是一个复数，是一个集合来表示。

例子四给箱子里面套箱子，结构化

比如说查询某家公司下面的某个员工？

/api/employees/1 这样写似乎没有什么问题，但是呢？这样写还是存在某些问题的，因为这样没有体现好资源结构。

如果这样写是不是更好，/api/companies/1/employees/1,这样写是否更好一点？这样在api层面暴露出了更多的信息，比如说知道了员工是在某个公司下面。

这样体现了一个很好的结构性。

例子五不要让restful作为约束

比如说我们可能看到这样的api，/api/users/allcount,这样写是不符合restful api的，表示获取users的数量，因为这不能把allcount 作为一个箱子，因为他的来源于users，users才是一个资源箱。

那么这样写是否正确呢？当然是不符合的了，但是有存在的合理性。因为如果这样写/api/users？search='allcount',这样写当然也是错误的了，因为/api/users获取的是users资源，得到的结果却是一个数量，

而且这样写让我们的代码混乱不堪。当然我们也可以提取出去，/api/statistics？name='users'&&result='allcount',这样写也会混乱不堪。那么就把这个当做一个箱子的特殊的孔，其合理性也很高。

所以说不能把restful完全作为一种不可抵触的东西，主要是看这个资源箱的结构是怎么样的。就像这个例子一样，在这个api接口资源库中，在users打个孔，真的没啥的，就跟一个机箱一样，里面存着一些外设

usb接口，如果没有这些接口的话，那么其扩展性太差了。

结

简单的做个介绍，后续持续不断更新。