美文网首页
DRF初识,以及CORS

DRF初识,以及CORS

作者: 上帝大人 | 来源:发表于2019-09-28 20:14 被阅读0次
    • 开发模式
    • 普通开发方式(前后端一起写)
    • 前后端分离
    • 后端开发:
    • 永远返回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请求的头部包括OriginAccess-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。

    相关文章

      网友评论

          本文标题:DRF初识,以及CORS

          本文链接:https://www.haomeiwen.com/subject/vqrayctx.html