Спецификация языковых агностиков

user1452030 спросил: 03 февраля 2018 в 10:38 в: configuration

Одним из требований моего текущего проекта является выбор целевого URL-адреса для клиента на основе определенных условий, и эти условия могут иметь операторы AND / OR и также иметь вложенные условия. Закодированный подготовленный пример:

if (device == 'android' || device == 'iOS') {
    if ( (flag1 == 'x' && productId == 'ABC123') || (flag1 == 'y' && productId == 'EFG345') ) {
      return url1;
    }
}
else if (device == 'mac' || device == 'windows') {
   ...
}

Довольно просто, если вы строите эту услугу, но наша задача состоит в том, что эта логика должна поставляться нашим поставщикам, которые заботятся о URL-адрес для определенных разделов нашей клиентской базы, и все они используют разные языки реализации - Java, Go-Lang, Python, вы называете это.

Вопрос заключается в том, что такие переменные, как device, flag1, productId и т. д. уже заполнены, существует ли языковой способ определения этих правил, например, в JSON?

Я посмотрел: Представление логики как данных в JSON

, и мне нравится предлагать использовать что-то вроде:

["AND",
    {"var1" : "value1"},
    ["OR",
        { "var2" : "value2" },
        { "var3" : "value3" }
    ]
]

Но я не вижу никаких стандартных парсеров, которые могут читать этот JSON и применять правила на определенном языке выбора. Существуют ли какие-либо стандартные решения, чтобы помочь с этим требованием, не имея нескольких настраиваемых парсеров и реализаций, подверженных ошибкам?

PS: Мы можем, чтобы каждый из наших поставщиков писал свой собственный фрагмент для этой логики выбора , но проблема заключается в том, что правила могут меняться довольно часто, и мы не хотим ждать, пока несколько разных компаний будут внедрять изменения кода в свои системы каждый раз, когда мы меняем правило. Мы также подумали о написании услуги и о том, что продавцы звонят нам, так что есть централизованный доступ к этим правилам, но это означает дополнительный сетевой вызов (или иметь кэш и продолжать опрос нашей службы). Кроме того, не все поставщики открыты для идеи вызова службы во время выбора URL.

0 ответов