我们的团队创建了一堆自定义REST API（v1 / resources / ...），并将它们作为企业服务提供给其他利益相关者，这些利益相关者不需要了解MarkLogic。但是，我们的团队负责在MarkLogic中创建，增强和维护服务器端脚本（我们使用JavaScript）。
在创建自定义REST API时，为了满足搜索要求，我们当前的设计是从查询选项开始，在查询选项中包含尽可能多的要求，以及查询选项无法满足的任何要求（例如，排序）文档中的复杂XPath，与其他文档的合并等），Java Script扩展程序中的代码（技术上不是转换，但从概念上讲类似于转换）。
随着查询选项的限制，越来越多的我们的大多数逻辑都进入了Javascript扩展程序，而查询选项似乎只是维护开销。我们真的需要为每个REST扩展维护一个查询选项文件，而转换提供了强大的功能吗？我可以摆脱查询选项而只使用服务器端Java脚本代码（从概念上讲，类似于转换）？最初，我们认为查询选项是基于配置的，因此更改查询选项并不完全是代码更改，但是，根据我们的经验，我们意识到更改查询选项还涉及部署，回归测试和所有其他活动。因此，在我们的例子中（创建自定义REST API），我看不到查询选项的任何特定优势。
设计大师，请提出建议！
答案 0 :(得分：0)
如果不正确了解整体情况，很难回答这些问题。您谈论的是自定义REST终结点，但是为此目的在内置REST api上使用REST扩展。您是否还在使用内置的REST API？您使用搜索选项，但不将其用于/ v1 / search。您可以对/ v1 / search使用这些选项执行相同的操作，但是在顶部使用额外的REST转换吗？您谈到在子文档级别上发生了许多数据处理。您是否考虑过先做一部分处理，还是以不同的方式组织数据，以便在请求时处理变得更加简单？
很多问题，很多可能性。对于这样一个悬而未决的问题，很难给出一个直接的答案。我仍然希望我能有所思索。
HTH！