• 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是什么版本信息。

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


  • 相关阅读:
    HDU1050
    POJ3528移石头
    CodeForces230A
    lca学习题
    rmq的st算法模板题 nyoj 119
    rmq问题和lca可以相互转化
    rmq算法,利用倍增思想
    poj 1274 基础二分最大匹配
    hdu 1520 树形dp入门题
    poj 1466 最大独立集
  • 原文地址:https://www.cnblogs.com/1314520xh/p/11261532.html
Copyright © 2020-2023  润新知