### RESTful API的请求类型有哪些？ GET 从服务器取出资源 POST 在服务器新建一个资源 PUT 在服务器更新资源（客户端提供改变后的完整资源） PATCH 在服务器更新资源（客户端提供改变的属性） DELETE 从服务器删除资源 HEAD 获取资源的源数据 OPTION 获取信息 关于资源的那些属性是客户端可以改变的 接口的安全性 1. 选https协议代替http协议这样，避免明文传输数据 2. 对一些开放的接口做数字签名 3. 对有登录操作的接口，先通过登录获取访问的令牌，之后访问其他需要登录的接口 通过携带这个令牌进行访问。 登录认证机制中session和jwt对比 session的登录原理： 客户端（client） 提交 用户名 密码（或验证码）给服务端(server)，服务端校验通过后， 服务端会生成身份认证相关的session数据,服务端将session数据保存在文件或者内存中，并且将session_id 返 回给客户端，客户端将返回的session_id保存在cookie中。此后客户端请求服务端时都会在cookie中携带session_id。 服务端通过校验session信息是否存在，如果存在判断用户是否处于登录状态以及用户具有的权限。通过校验就返回该有的 数据，没通过校验返回登录页。 session 的优势和劣势 优势： 1. session可以主动清除 2. session保存在服务端相对安全 3. 结合cookie使用 较为灵活 兼容性好 劣势： 1. cookie+ session 在跨域场景下表现不好 2. 如果是分布式部署，需要多机器共享session机制，实现方法可将session存储到数据库或者redis 中，这样查询session信息时需要进行数据库的操作 3. 基于cookie的机制很容易被CSRF攻击 jwt 的登录原理： 客户端（client） 提交 用户名 密码（或验证码）给服务端(server)，服务端校验通过后，将用户的 id 和其它信息做为JWT playload(负载)，将其与头部分别进行Base64编码拼接后签名，形成一个JWT,形成的JWT就是 形同，lll.zzz.xxx的字符串。后端将JWT字符串作为登录成功的返回结果，返回给前端。前端可以将返回结果保存在localStorge 或sessionStorage上，退出登录前删除保存的JWT即可。前端在每次请求时将JWT放在http header中的Authorization位 （解决XSS和XSRF攻击）。后端检查是否存在，如果存在验证JWT的有效性。例如检查签名是否正确，检查token是否过期 检查token的接受方是否是自己（可选）验证通过后，后端使用JWT中包含的用户信息进行其他的逻辑操作，返回相应的结果。 jwt 和 session的区别 session 的状态是存储在服务端的，客户端只存储session_id ,而token的状态存储在客户端 （因为信息全部放在客户端所以需要密码学的方法进行签名和加密） 分布式系统中session 共享是一个问题，session存在服务端，随着用户数量增多，会大幅降低服务端的性能 在多个域名下，会存在跨域问题，安全性方面cookie保存在本地，容易被人利用进行CSRF攻击