我们的团队创建了一堆自定义 REST API (v1/resources/...) 并将它们作为企业服务公开给其他不需要了解 MarkLogic 的利益相关者。但是,我们的团队负责在 MarkLogic 中创建、增强和维护服务器端脚本(我们使用 JavaScript)。
在创建自定义 REST API 时,我们当前满足搜索要求的设计是从查询选项开始,在查询选项中包含尽可能多的要求,以及查询选项无法满足的任何要求(例如,在文档中排序、复杂的 XPath、与其他文档合并等)、Java Script 扩展程序中的代码(技术上不是转换,但在概念上类似于转换)。
随着查询选项的限制,我们的大部分逻辑越来越多地进入 Javascript 扩展程序,查询选项似乎只是一种维护开销。我们真的需要为每个 REST 扩展维护一个查询选项文件,而转换提供了强大的功能吗?我可以摆脱 Query 选项而只使用服务器端 Java Script 代码(从概念上讲,类似于转换)吗?最初,我们的想法是查询选项是基于配置的,因此更改查询选项并不完全是代码更改,但是,根据我们的经验,我们意识到更改查询选项还涉及部署、回归测试和所有其他活动。因此,在我们的案例中(创建自定义 REST API),我看不到查询选项的任何特定优势。
设计大师,请指教!