参见 http://openerp.com/wiki/index.php/Developers:Developper%27s_Book/Interfaces/InterfaceXMLRPC/Python
可见暴露出两个服务 xmlrpc/common和xmlrpc/object,前者提供通用的功能,如用户验证,后者提供对openerp objects的访问,日后也可能会按这个惯例增加report/workflow之类的访问接口
这里需要提的是两点
1. 参数传递做的不够漂亮
①返回的是一个uid 而不是个令牌
uid=sock_common.login(dbname,username,pwd)
②在后面的方法调用中传递dbname,uid,pwd 而不是传递令牌
sock.execute(dbname,uid,pwd,'res.partner','create',partner)
理想的方法应该是返回一个令牌
sock.execute(token,'res.partner','create',partner)
这个应该是设计上的问题,估计以后也不会改了
2.这里可以看一下api的设计,是泛化的, 访问objects的方法仅仅是一个execute 方法,这同我早先一个blog的想法如出一辙 http://www.cnblogs.com/jjx/archive/2007/08/15/856559.html
其实类似axapta的business connector也是类似的. 这反应了api的设计的一个设计原则. 暴露过于细节的接口是很难顺应变化的(太多的接口需要在后期变动,大多的接口需要通过uri暴露)
可见暴露出两个服务 xmlrpc/common和xmlrpc/object,前者提供通用的功能,如用户验证,后者提供对openerp objects的访问,日后也可能会按这个惯例增加report/workflow之类的访问接口
这里需要提的是两点
1. 参数传递做的不够漂亮
①返回的是一个uid 而不是个令牌
uid=sock_common.login(dbname,username,pwd)
②在后面的方法调用中传递dbname,uid,pwd 而不是传递令牌
sock.execute(dbname,uid,pwd,'res.partner','create',partner)
理想的方法应该是返回一个令牌
token=scok_common.login(dbname,username,pwd)
然后在服务器端维护token和用户的关系,在后面方法中传递令牌
sock.execute(token,'res.partner','create',partner)
这个应该是设计上的问题,估计以后也不会改了
2.这里可以看一下api的设计,是泛化的, 访问objects的方法仅仅是一个execute 方法,这同我早先一个blog的想法如出一辙 http://www.cnblogs.com/jjx/archive/2007/08/15/856559.html
其实类似axapta的business connector也是类似的. 这反应了api的设计的一个设计原则. 暴露过于细节的接口是很难顺应变化的(太多的接口需要在后期变动,大多的接口需要通过uri暴露)
