使用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，终究不是一个非常理智和容易实现的目标。