开发者学堂课程【高校精品课-厦门大学 -JavaEE 平台技术：RESTfulAPI设计】学习笔记，与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/80/detail/15971
RESTfulAPI设计
url 设计的思想
https://app.swaggerhub.com/apis/mingqen/OOMALL/1.0.17#/privilege/
url 的设计是用resfor风格设计的，所以在 Java1这门课里面花时间讲解了resfor的风格怎样设计。
下面有几个原则：
1、尽量使用复数名词。可以看到前面说的全系统里面说的三大实体：用户、角色、权限。分别是这里面的主要的东西。可以看到权限系统是比较简单的，三个实体，三个关系，六个东西。
所以90%的 url都是为了维护这三个东西和这三个关系的。最终的目的就是为了用户
有什么权限。所以只有一个功能，其他的都是为了维护三个东西和这三个关系的。
现在选择一些比较特殊的地方来讲，可以看到有几个比较特殊的地方，一个是GET/user/myself 这个 url主要的作用是获得用户自己的信息。
定义了这样的用户信息是需要登录的，不登录是不行的，前面讲是需要wt做的，每一个具体的请求，如果登录之后头上面应该都会带一个前缀：authorization，而且这个前缀是必须带的，不带的话说明没有登录。Require就是产生的硬盘，就是看不懂的防篡改的硬盘。带过来让服务器检查这个东西是谁。以上就是头的内容。
其他就没有了，后面的是 response 的内容，response 就是返回值。
Resfor 注意返回的就是用户的信息，可以比较一下用户的信息和数据库中的信息还
有对象模型中的信息，发现他们是不一样的。
为什么不一样呢？例如这里没有密码。拿到一个用户信息将密码返回前端，听起来很荒谬，所以密码是不能返回的。
Emil、Mobil 都没有，这个东西就是在后台控制的，如果 Emil、Mobil 没有确认过的话，这个用户是不能做任何动作的。所有的动作都不能做，只能停下来什么都不能干，没有任何权限。只有 xxx了，才可以做其他的工作，所有那些是给用户控制逻辑的，反伪用户的时候就看不到有没有。
Bedileteted 在数据库里面有，但是对象里面没有，在这里更没有。为什么？因为那个是数据库里面被逻辑删掉了，如果一个对象被数据库逻辑删掉了，那么 url就再也回不来了。就是不能把这个对象再回来，不能登录，也不能看到自己的信息，
唯一在这里面能用到的作用就指定在数据库中有这条记录。
因为这里没有涉及到订单等。权限系统里面如果用户被删除了，用户与角色的关系也切断了，就剩下一个用户最基本的信息留在了数据库里面，他是被删除的。这个是在对象模型中没有的，对象模型永远不会实例画出被删除的用户对象，那么这里更加不可能了。所以在 Java1设计的时可以看到例子中间是有几类对象的。一类是vo 对象，是指诚信给用户看的对象，或者是接收用户的输入数据的对象。另一类是在里面完成功能逻辑的对象；还有一类是存在数据库里面的东西。当然因为我们用
的是 xxx存到数据库中的对象，叫做持久化的对象，基本上是与数据库一一对应的。所以至少是有三类对象的，如果在 redis里面存的话，还有第四类对象。如果还有消息放发的话，还有第五类对象。所以对象是无所不在的，对象会在整个代码
中到处都有，所以我们需要为在不同的东西在不同的时间描述不同的对象。
可能之前在写代码的时候会偷懒，很多初学者写代码会将数据库作为一个对象，从
头写道尾。从界面就把数据库对象写进去，一直往下传。这是绝对不安全的。
为什么呢？例如注册用户。
xxx有一种非常不好的写法，就是把数据库的部分用自动的插件插件产生，形成通用的数据库操作的代码。然后将 PO 对象一直弄到表面上面来。这样做会有很大的隐患，例如注册用户，注册用户能够提供的属性就是它能够写的：用户名、密码、姓名、电话号。比如说是否禁止登录还是不禁止登录，是不能写的。比如说邮件是不
是有确认，也是不能写的。是不是 delete，也不让写的。如果那样做的话，前端可以传过来一个阶层，将数据库中所有字段的值都设置好，然后一路上就写入数据库中了。
所以我们的课程设计不主张100%使用自动生成的代码，不是不能使用自动生成的代码。而是需要搞懂那些地方是可以用自动生成的代码的。哪些地方不能用自动生成
的代码。
除了 GET/user/myself还有另外一个get。这个get用用户名和电话号码。然后去查
找用户，下面是由分页的，因为可能会查出多个。
从功能上来说，查当前用户的信息和这个是可以公用的。用这个 API将当前登录用户名带过来就可以查得到当前登录的用户信息。那么为什么在 url上设计两个呢url？是因为权限的原因。因为查看这里的信息这个东西是没有权限的，所以本身权
限管理系统的权限由自己来管的，这个是由零道口。权限管理系统的权限由自己来管的。
包括哪些用户能够新增加角色等都是由自己来管的。所以查看自己信息这个东西在权限里面就没有这一套，这个是不用管权限的，只要登录了就可以查到自己的信
息。但是上面 get user 是需要管权限的。因为不是所有的用户可以任意查看用户的信息的，所以需要管权限。
PUT 也是类似的，认为 PUT 就是修改东西，但是这里的修改东西写了三条。修改自己的信息，修改密码，重置密码。
为什么写了三条？可以看一下修改自己信息是不能改密码的，只能修改姓名、头像、电话和邮箱。要修改密码需要重置，提供自己的电话号码和邮箱重置密码，然
后会在邮箱内发一个验证码，使用验证码在上面修改密码。所以是这样的逻辑，这样的话就会更加安全一点。小的设计的细节大家需要自己了解。
可以说里面所有的 API，除了最后的 API以外，前面基本上都是增删改查。就是为了维护用户、角色和权限的对象和他们之间的关系。对于这个例子来说，它的所有东西的目的就是为了 user ID permission，查询某一个用户是否有权限。另一个还有查询当前登录用户是否有权限。
User ID 然后需要访问什么，总的风格原则来说，要返回的东西是最后一个名词。User ID privilege，返回的就是 privilege。前面是最后这个名词的限定，指的是这个用户的 privilege。
当然在所有的 url 里面是有一些 url 是特例的。不是以名词结尾的，例如 POST和GET 这两个没有办法想出来一个名词登录和退出。所有的系统都是做不到的。还有
一个 reset。除了这三个以外，所有的 url 都是符合风格的。
在做的时候建议（目前课件中的比较简单）看一下豆瓣中的API。豆瓣的API是国内风格做的最好的 API。看到的好换标准是和这个一样的。看到的任何的规矩是做的很好的，动词很少，返回的东西或者操作的东西都是最后的一个名词。前面的名词
是最后的名词的限定语。
就是以这样的方式做 url，比如说 delete，是删除某个用户的某一个角色。
所以知道删除的是什么，删除的是角色。删除的是某个用户的某个角色，所以它用
这样的方式表示它的从属关系，上面的都是一样的。
