使用revit api 提供web api

这里是提供一种思路,一个已经完成了的,但是并不一定是最优的方式。

revit 的api 是用于打开软件时,调用软件,来进行画图等操作,比如绑定到revit软件界面中的某个地方,提供一个可以点击调用的方式。

也或者供点击后,弹出窗体程序,来实现在自定义的界面中,对revit api 进行操作,完成画图等操作。

通常,这就是我之前接触到的,关于基于revit api 做插件开发。

但是,现在的目标是,这个东西要提供一个web api,供别的人远程调用——大致理解为,远程调用通过json传递规范数据,来完成revit软件的操作,并形成文档保存下来——其实我们只是想能够通过web api的形式自动设生成revit 文件,而revit api 的使用形式是必须要软件打开,所以,也就成了打开这个revit 软件并提供一个web api。

再次明确目标:使用revit 的api 提供 web服务。

首先,最开始想到的是写一个同步函数,监听端口,循环处理。

事实证明,这样是可行的,至少实现了一个web api,但是,在revit这个软件的界面,完全卡死——因为我们的程序已经阻塞在了监听上。这里就有了windows 上窗体程序的一个循环机制——事件机制。

其次想到的是,多线程或者多进程——但是这个完全行不通——至少直接线程,在需要transaction时,是有问题的。暂时放弃了。

最后想的是,能不能把web api 写成一个基于事件循环来回调的异步服务,访问的事件能够当作自定义的界面里面的点击按钮——虽然这个没让我实际的解决问题,但是,从原本的自定义窗体程序,调用revit api 方法中,handler和event的raise机制,我想到了在异步中回调,handler和event。

事实证明,写成异步,同时在回调函数中调用event和handler是可以的。不光提供了web api,而且不会造成因为监听带来的阻塞,可以很简单的打开关闭revit软件。

为什么要在回调中调用event和handler的raise?

首先呢,我想说,如果直接在回调函数中,按照普通调用revit api 的方式,是会出错的,什么错呢?revit程序直接崩溃了。这里使用form中的调用方法也是在遇到了直接调用会崩溃才想到的。

这样的revit web api 性能怎么样?

从目前,2018年6月27日的完成情况来看,效果是有了,比较清爽,但是,性能应该不好。首先,虽然它是基于事件的异步web api,但是,它在接收处理方面,它只是一个单进程,单线程的东西,并且处理的过程是阻塞的,并不能如同协程那样,处理一半暂停一下,去接收新的请求。

我们试图在线程中使用revit 的api,或者改变成为一个能够像协程那样暂停处理的web 接口。

revit api 不能支持线程?

事实来看,至少它不支持线程的通常用法。

从较多的资料来看,revit支持多线程,不过多线程里面不能使用transaction,但是这是画图必须的,和我的目标是有偏差的。

也有一种思路,准备去尝试,就是在线程中,通过handler和event的raise机制来调用revit的api,查阅资料有人说这样可以,但是还没验证。如果可以,这将是我心目中,提升 这个web api 性能的最好路径——去通过异步构建类似协程的web api,终究不是一个非常理智和容易实现的目标。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180627G1EM9V00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券