RestfulApi 学习笔记——简单介绍（一）
- 2020 年 11 月 1 日
- 筆記
- .net core(web)
前言
什么是restapi？
直接看：//www.ruanyifeng.com/blog/2014/05/restful_api.html
阮一峰的blog，即可明白，下面是一些例子，增强理解。
正文
例子一 资源链是箱子
比如说我们要得到某个用户，我们可能这样写:api/getusers
这样就不符合了，因为操作动作让请求方式替代。
比如说get 请求就表示是获取users，那么就不需要写get，那么可以这样写:api/users 然后get请求。
这个怎么说呢？也就是说把资源链当做资源链，而不是语义，说简单点就是资源链指向的是某个资源，而不是某个操作。
那么如果获取方式不同怎么写呢？比如说查询按照某个字段从小到大排序，那么应该如何写呢？我们需要明白查询从小到大排序是条件，而不是动作。
那么可以作为参数来传递api/users?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接口，如果没有这些接口的话，那么其扩展性太差了。
结
简单的做个介绍，后续持续不断更新。
