zoukankan      html  css  js  c++  java
  • odoo中接口开发

    文章参考:https://blog.csdn.net/qq_33472765/article/details/81913627


    案例0000001

    接口调用请求说明:
    https请求方式:GET(请使用https协议)
    csrf=False
    csrf(Cross-site request forgery跨站请求伪造)问题,get请求不影响,post就需要csrf认证
    CSRF(跨站请求伪造)
    CSRF 英文全称为 Cross SIte Request Forgery
    CSRF 通常指恶意攻击者盗用用户的名义,发送恶意请求,严重泄露个人信息危害财产的安全


    @http.route('/forum/get_url_title', type='json', auth="public", methods=['POST'], website=True)
    def get_url_title(self, **kwargs):
    try:
    req = requests.get(kwargs.get('url'))
    req.raise_for_status()
    arch = lxml.html.fromstring(req.content)
    return arch.find(".//title").text
    except IOError:
    return False


    响应数据格式:json
    响应数据例子:
    {
    "data":ODOO_DATA

    "result":{

    "other_field":[]

    "state":TRUE
    }
    }


    对方通过:
    http://127.0.0.1:8069//forum/get_url_title 传送json数据过来:







    二、情况2:发送数据给其他系统【执行函数】
    1.调用其他系统做的服务接口:
    案例0002:查询数据案例:
    步骤1:做一个统一登陆的函数:a:用户名、b:密码、c:密钥【自动生成的密钥]
    步骤2:传入查询条件参数:调用接口服务函数执行查询:【定义好服务端返回的数据格式json】
    步骤3:将查询好的数据解析:存储在本系统中 re_data = json.dumps(test_data)




    """
    #REST 与 SOAP 与 XML-RPC

    具体介绍:


    """ API接口开发总结:
    什么是接口
    接口无非就是客户端请求你的接口地址,并传入一堆该接口定义好的参数,通过接口自身的逻辑处理,返回接口约定好的数据以及相应的数据格式
    接口怎么开发

    接口由于本身的性质,由于和合作方对接数据,所以有以下几点需要在开发的时候注意:
    定义接口入参:写好接口文档
    定义接口返回数据类型:一般都需要封装成一定格式,确定返回json还是xml报文等


    #一、情况1:接收从其他系统传过来的数据:一般用http 形式数据格式json格式的。

    1. 使用GET、POST、PUT、DELETE这几种请求模式

    请求模式也可以说是动作、数据传输方式,通常我们在web中的form有GET、POST两种,而在HTTP中,存在下发这几种。

    GET (选择):从服务器上获取一个具体的资源或者一个资源列表。
    POST (创建): 在服务器上创建一个新的资源。
    PUT(更新):以整体的方式更新服务器上的一个资源。
    PATCH (更新):只更新服务器上一个资源的一个属性。
    DELETE(删除):删除服务器上的一个资源。
    HEAD : 获取一个资源的元数据,如数据的哈希值或最后的更新时间。
    OPTIONS:获取客户端能对资源做什么操作的信息。


    常见的请求参数
    比如在数据过多, 需要对数据进行分页请求的时候, 我们应该统一 API 请求参数. 常见的有这些.

    limit=10 指定返回记录的数量
    offset=10 指定返回记录的开始位置。
    page=2&per_page=100 指定第几页,以及每页的记录数。
    sortby=name&order=asc 指定返回结果按照哪个属性排序,以及排序顺序。
    animal_type_id=1 指定筛选条件



    3.json数据类型

    接口的数据一般都采用JSON格式进行传输,不过,需要注意的是,JSON的值只有六种数据类型:

    Number:整数或浮点数
    String:字符串
    Boolean:true 或 false
    Array:数组包含在方括号[]中
    Object:对象包含在大括号{}中
    Null:空类型


    4.返回的数据结构



    服务器返回的数据结构,一般为:

    {
    code:0,
    message: "S",
    data: { key1: value1, key2: value2, ... }
    }

    code: 返回码,0表示成功,非0表示各种不同的错误
    message: 描述信息,成功时为"success",错误时则是错误信息
    data: 成功时返回的数据,类型为对象或数组

    不同错误需要定义不同的返回码,属于客户端的错误和服务端的错误也要区分,比如1XX表示客户端的错误,2XX表示服务端的错误。这里举几个例子:

    0:成功
    100:请求错误
    101:缺少appKey
    102:缺少签名
    103:缺少参数
    200:服务器出错
    201:服务不可用
    202:服务器正在重启




    5. 使用SSL(https)来提供URL
    首先,使用https可以在数据包被抓取时多一层加密。我们现在的APP使用环境大部分都是在路由器WIFI环境下,一旦路由器被入侵,那么黑客可以非常容易的抓取到用户通过路由器传输的数据,如果使用http未经加密,那么黑客可以很轻松的获取用户的信息,甚至是账户信息。
    其次,即使使用https,也要在API数据传输设计时,正确的采用加密。例如直接将token信息放在URL中的做法,即使你使用了https,黑客抓不到你具体传输的数据,但是可以抓到你请求的URL啊!(查了资料了,https用GET方式请求,也仅能抓到域名字符部分,不能抓到请求的数据,
    但是URL可以在浏览器或特殊客户端工具中直接看到。多谢下面的朋友指正错误)因此,使用https进行请求时,要采用POST、PUT或者HEAD的方式传输必要的数据。



    6.TOKEN

    现在,大部分App的接口都采用RESTful架构,RESTFul最重要的一个设计原则就是,客户端与服务器的交互在请求之间是无状态的,也就是说,当涉及到用户状态时,每次请求都要带上身份验证信息。实现上,大部分都采用token的认证方式,一般流程是:

    用户用密码登录成功后,服务器返回token给客户端;
    客户端将token保存在本地,发起后续的相关请求时,将token发回给服务器;
    服务器检查token的有效性,有效则返回数据,若无效,分两种情况:
    token错误,这时需要用户重新登录,获取正确的token
    token过期,这时客户端需要再发起一次认证请求,获取新的token

    然而,此种验证方式存在一个安全性问题:当登录接口被劫持时,黑客就获取到了用户密码和token,后续则可以对该用户做任何事情了。用户只有修改密码才能夺回控制权。

    如何优化呢?第一种解决方案是采用HTTPS。HTTPS在HTTP的基础上添加了SSL安全协议,自动对数据进行了压缩加密,在一定程序可以防止监听、防止劫持、防止重发,安全性可以提高很多。不过,SSL也不是绝对安全的,也存在被劫持的可能。另外,服务器对HTTPS的配置相对有点复杂,还需要到CA申请证书,而且一般还是收费的。而且,HTTPS效率也比较低。一般,只有安全要求比较高的系统才会采用HTTPS,比如银行。而大部分对安全要求没那么高的App还是采用HTTP的方式。

    我们目前的做法是给每个接口都添加签名。给客户端分配一个密钥,每次请求接口时,将密钥和所有参数组合成源串,根据签名算法生成签名值,发送请求时将签名一起发送给服务器验证。类似的实现可参考OAuth1.0的签名算法。这样,黑客不知道密钥,不知道签名算法,就算拦截到登录接口,后续请求也无法成功操作。不过,因为签名算法比较麻烦,而且容易出错,只适合对内的接口。如果你们的接口属于开放的API,则不太适合这种签名认证的方式了,建议还是使用OAuth2.0的认证机制。

    我们也给每个端分配一个appKey,比如Android、iOS、微信三端,每个端分别分配一个appKey和一个密钥。没有传appKey的请求将报错,传错了appKey的请求也将报错。这样,安全性方面又加多了一层防御,同时也方便对不同端做一些不同的处理策略。

    另外,现在越来越多App取消了密码登录,而采用手机号+短信验证码的登录方式,我在当前的项目中也采用了这种登录方式。这种登录方式有几种好处:

    不需要注册,不需要修改密码,也不需要因为忘记密码而重置密码的操作了;
    用户不再需要记住密码了,也不怕密码泄露的问题了;
    相对于密码登录其安全性明显提高了。


    7.用户设计

    显式用户和隐式用户,我不知道这两个词用的是否确切。
    显式用户指的是,APP程序中有用户系统,一个username、password正确的合法用户,称之为显式的用户,
    通常显式用户都需要注册,登录以后能完成一些个人相关的操作。

    隐式用户指的是,APP程序本身就没有用户系统,或者一个在没有登录的情况下,使用我们APP的用户。
    在这种情况下,可以通过客户端生成的UDID来标识一个用户。

    有了用户信息,我们就能够了解不同用户的使用习惯,而不仅仅是全体用户的一个整体的统计信息,
    有了这些个体的信息之后,就可以做一些用户分群、个性化推荐之类的事情。

    如果是SAAS版本,还需要区分不同商户的用户




    8.良好的接口说明文档和测试程序

    接口文档有时候是项目初期就定下来的,前后端开发人员按照接口规范开发,
    有的是接口开发完成后写的。
    接口文档要清晰、明了,包含多少个接口,每个接口的地址、参数、请求方式、数据交换格式、返回值等都要写清楚。

    接口测试程序,有条件的话,也可以提供,方便前后端的调试。



    如果是springMVC开发的话,可以用swagger,后端只要加几个注释发一个url给前端就可以了,轻松又高效。




    9.接口统计功能

    在做PC端网站的时候,我们都会给我们的网站加上个统计功能,要么自己写统计系统,要么使用第三方的比如GA、百度等。
    移动端接口API则需要我们自己实现统计功能,
    这时就需要我们尽可能多的收集客户端的信息,除了传统的IP、User-Agent之外,还应该收集一些移动相关的信息,
    比如
    手机操作系统,是android还是ios,都是什么版本,
    用户使用的网络状况,是2G、3G、4G还是WIFI
    客户端APP是什么版本信息。

    这样,有助于我们更好的了解我们用户的使用


  • 相关阅读:
    matplotlib数据可视化之柱形图
    xpath排坑记
    Leetcode 100. 相同的树
    Leetcode 173. 二叉搜索树迭代器
    Leetcode 199. 二叉树的右视图
    Leetcode 102. 二叉树的层次遍历
    Leetcode 96. 不同的二叉搜索树
    Leetcode 700. 二叉搜索树中的搜索
    Leetcode 2. Add Two Numbers
    Leetcode 235. Lowest Common Ancestor of a Binary Search Tree
  • 原文地址:https://www.cnblogs.com/1314520xh/p/11261532.html
Copyright © 2011-2022 走看看