MarkLogic: вопрос о дизайне для search.search против API CTS - PullRequest
0 голосов
/ 22 ноября 2018

MarkLogic версия 9.0-6

Наша команда создает несколько пользовательских REST API (v1 / resources / ...) и представляет их в качестве корпоративных сервисов другим заинтересованным сторонам, которым не нужно ничего знать оMarkLogic.Тем не менее, наша команда отвечает за создание, улучшение и поддержку серверных сценариев (мы используем JavaScript) в MarkLogic.

При создании пользовательских API REST наша текущая задача - использовать API search.search для удовлетворения любыхпоисковые требования.В последнее время я все больше склоняюсь к использованию более гибких и быстрых функций CTS, поскольку не вижу особых преимуществ использования API-оболочки оболочки search.search.Поскольку моя команда в основном занимается написанием кода и поддержкой серверных сценариев, я думаю, что лучше использовать API низкого уровня (функции CTS), которые предлагают большую гибкость и скорость, чем тратить время на создание API высокого уровня (search.search или jsearch).) работать или, что еще хуже, перекодировать в функции CTS позже в будущем, потому что особые сложные функциональные возможности не могут быть реализованы с помощью API высокого уровня.

Гуру дизайна, пожалуйста, предложите!

1 Ответ

0 голосов
/ 22 ноября 2018

JSearch, Search API, Optic API, все очень хорошие инструменты, разработанные и поддерживаемые командой MarkLogic Core Engineering.Я долго думал, прежде чем отложить их в сторону.Мудро ли это в вашем случае, это может зависеть.Может быть, вы упустили из виду функции, которые будут вам очень полезны.Например, некоторые ограничения в API поиска можно преодолеть, используя search.parse() и search.resolve() вместо search.search().Использование CTS напрямую не является плохой практикой, но вы можете легко изобрести колесо заново.

Задавайте конкретные вопросы и делитесь определенными частями кода с соответствующими вопросами, чтобы получить конкретные ответы.Этот форум не очень подходит для таких открытых вопросов, поскольку на них часто нет прямого и ясного ответа.

HTH!

...