0

我们的团队创建了一堆自定义 REST API (v1/resources/...) 并将它们作为企业服务公开给其他不需要了解 MarkLogic 的利益相关者。但是，我们的团队负责在 MarkLogic 中创建、增强和维护服务器端脚本（我们使用 JavaScript）。

在创建自定义 REST API 时，我们当前满足搜索要求的设计是从查询选项开始，在查询选项中包含尽可能多的要求，以及查询选项无法满足的任何要求（例如，在文档中排序、复杂的 XPath、与其他文档合并等）、Java Script 扩展程序中的代码（技术上不是转换，但在概念上类似于转换）。

随着查询选项的限制，我们的大部分逻辑越来越多地进入 Javascript 扩展程序，查询选项似乎只是一种维护开销。我们真的需要为每个 REST 扩展维护一个查询选项文件，而转换提供了强大的功能吗？我可以摆脱 Query 选项而只使用服务器端 Java Script 代码（从概念上讲，类似于转换）吗？最初，我们的想法是查询选项是基于配置的，因此更改查询选项并不完全是代码更改，但是，根据我们的经验，我们意识到更改查询选项还涉及部署、回归测试和所有其他活动。因此，在我们的案例中（创建自定义 REST API），我看不到查询选项的任何特定优势。

设计大师，请指教！

4

1 回答 1

0

如果不正确了解整个情况，这些问题很难回答。您谈论的是自定义 REST 端点，但为此目的在内置 REST api 上使用 REST 扩展。您还在使用其他内置 REST api 吗？您使用搜索选项，但不要将它们用于 /v1/search。您是否可以使用这些选项对 /v1/search 进行相同的操作，但在顶部添加一个额外的 REST 转换？你说在子文档级别发生了很多数据修改。您是否考虑过预先进行部分处理，或者以不同的方式组织数据，以便在请求时处理变得更加简单？

很多问题，很多可能性。对于这样一个悬而未决的问题，很难给出一个直接的答案。尽管如此，我希望我给了一些思考。

！

于 2018-11-22T19:30:13.180 回答