• 开发模式

• 普通开发方式(前后端一起写)
• 前后端分离

• 后端开发：

• 永远返回HttpResponse
• 为前端提供url( API的开发，接口的开发 )

• Django里面的FBV和CBV：

• 基于函数的视图
• 基于类的视图
  它是基于反射实现的,根据请求方法的不同，执行不同的函数。
  原理：
  url --> as_view方法-->view方法 -->dispatch方法（根据反射执行其它方法，get，post，put，delete...）
  面向对象

• 封装

• 对同一类方法封装到类中

class File():
      def add()
      def delete()
      def update()
      def get() 

• 将数据封装到对象中

对象是类的实例，也就是说实例化的时候将数据封装到对象中
class File():
      def __init__(self,a1,a2):
          self.a1 = a1
          self.a2 = a2

当实例化对象的时候
obj1 = File(123,666) #
obj2 = File(234,888)  #将数据分装到了对象中

Restful api

• 协议
  尽量使用HTTPs协议
• 域名
  两种方式：
  https://api.example.com要解决跨域问题
  https://example.org/api常用的方式
• 版本
  应该将api的版本号放在url中，在进行版本迭代时两个版本共存的情况能解决二义性
• 面向资源，网络上全是资源
  所以url中不能有动词
• method
  --get
  --post
  --put
  --patch
  --delete
  对应了查，增，改，小改，删。还有不常用的head(获取资源的元数据)和options(获取信息，关于信息哪些属性时客户端可以改变的)
• 过滤信息
  常用的过滤信息就是，分页，按照什么排序
• 状态码和code

常见的状态码：

200:请求成功； 201新建或者修改数据成功； 202 一个请求已经进入排队； 204 用户删除数据成功； 401 用户权限不足 403 访问禁止 404 请求的数据不存在 ； 410 ：请求的资源被永久删除； 500 内部服务器错误。

code自定义：

{ ' 1000 ': 'error' }

• 错误处理
  返回错误信息
  {
  error:"不存在的api接口"
  }
• 返回结果
  针对不同分http动作，返回结果对象
• Hypermedia API
  例子：
  用户访问/order 可得到所有订单

[ 
  { 
        id :1
        name :'the'
   },
  { 
        id :2
        name :'he'
   }
]

用户访问/order/1可获得id为1的订单的详细信息

{
  id : 1
  name:'the'
  count:9
  price:199
}

现在这种方式就是不友好的,下面这中有一个连接，就是友好的。

[ 
  { 
        id :1
        name :'the'
        url:'https://www.example.com/order/1'
   },
  { 
        id :2
        name :'he'
  url:'https://www.example.com/order/1'
   }
]

面试：谈谈对restful api的认识谈谈怎么实现跨站资源共享CORS

他本质上就是一些规范，让url更加的具体详细，容易区分，前后端交互更加简洁。

• 首先是域名api写在域名，或者写在url后面。写在域名中就可能会导致跨域问题(浏览器同源策略，https和http不同源，不同域名不同源，不同的端口不同源)

• 然后讲到跨域问题，请求发送了两次，一次option，一次post，option作预检，请求到达服务器，知悉服务器知否允许该实际请求，预检请求的使用，可以避免跨域请求对服务器的数据产生未预期的影响。

• 什么时候会首先发送预检请求？

• 使用了PUT，DELETE，PATCH，OPTIONS，CONNECT， TRACE任意一种http方法。
• 人为设置了对CORS安全的首部字段集合之外的其他首部字段。
• Content-Type的值不属于下列之一：application/x-www-form-urlencoded
  multipart/form-data
  text/plain
• 等

• 发送option请求，询问要被跨域的服务器是否允许在当前域名下的页面发送跨域请求。

• option请求的头部包括Origin，Access-Control-Request-Method, Access-Control-Request-Headers

• 服务器收到option后，设置Access-Control-Allow-Origin,Access-Control-Allow-Method, Access-Control-Allow-Headers头部与浏览器沟通来判断是否允许这个请求，Access-Control-Allow-Credentials为true，预检验证通过，浏览器才会发送真正的跨域请求。

• 总结
  https://yq.aliyun.com/articles/69313
  https://zhuanlan.zhihu.com/p/53996160

https://segmentfault.com/a/1190000015597029四种解决跨站请求访问

http://www.ruanyifeng.com/blog/2016/04/cors.htmlCORS跨站资源共享解决跨域问题

服务器的处理机制，当用户来了一个请求，先检查http头有没有origin字段，没有或者不允许，就是简单请求，

如果有且是允许的，那再看看是不是预检请求，如果是，发送Alllow-Headers，Allow-Method,内容为空
option也会携带Access-Control-Request-Method, Access-Control-Request-Headers头部和方法信息，如果服务器返回的Alllow-Headers，Allow-Method包含它，那么就是允许跨域的。

如果不是那就是简单请求，返回Allow-Orgin,Allow-Credentials（true相应，false不响应）

rest framework 源码流程

from restframework import APIView
写CBV类的时候继承APIView，他其实就是View的子类，但是丰富了一些内容

• 源码流程

url匹配，执行CBV的as_view方法，as_view方法返回的是一个内部函数view，这个内部函数执行dispatch()方法。

APIView的dispatch方法中将request对象作了加工，返回了一个Request()的对象,对象中包含了原来的request，想要调用就要使用request(新)._request。