Я реализую операцию SCIM PATCH в своей собственной библиотеке. Загляните сюда и здесь. В настоящее время работа над v2 продолжается, но возможности CRUD, необходимые для операций исправления, достигли зрелости.

Прежде всего, вам нужен способ анализа пути SCIM, который может дополнительно включать фильтр. Я реализую конечный автомат для анализа пути и фильтрации. Сканер будет просматривать каждый байт текста и указывать на интересные события, а синтаксический анализатор будет использовать сканер, чтобы разбить текст на значимые токены. Например, emails[value eq "[email protected]"].type можно разбить на emails, [, eq, "[email protected]", ] и type. Наконец, компилятор примет эти входные токены и соберет их в абстрактное синтаксическое дерево. На бумаге это будет выглядеть примерно так:

emails -> eq -> type
        /   \
     value  "[email protected]"

Затем вам нужен способ обхода структуры данных ресурса в соответствии с абстрактным синтаксическим деревом. Я разработал свою модель свойств, чтобы нести ссылку на атрибут SCIM. Рассмотрим следующий ресурс:

{
   "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
   "userName": "imulab",
   "emails": [
      {
         "value": "[email protected]",
         "type": "work"
      },
      {
         "value": "[email protected]",
         "type": "home"
      }
   ]
}

Я начинаю переход от корня ресурса и нахожу дочерний элемент с именем emails, который вернет свойство multiValued сложного типа. Я вижу, что мой следующий токен (eq) является корнем фильтра, поэтому я выполняю операции фильтрации для двух элементов emails. Для каждого элемента я иду вниз по value дочернему элементу и оцениваю его значение. Поскольку только первый элемент соответствует фильтру, я, наконец, перехожу к type дочернему элементу этого сложного свойства и достигаю целевого свойства. Оттуда вы можете выполнять Add, Replace и Remove операции.

Я рекомендую остерегаться двух вещей.

Одна вещь заключается в том, что ваш путь перехода будет разделен, когда вы нажмете свойство multiValued. В приведенном выше примере у нас есть только один элемент, соответствующий фильтру. На самом деле, у нас может быть много совпадений или может не быть фильтра вообще, что заставит вас пройти по всем элементам.

Другой - синтаксис пути SCIM. Спецификация требует, чтобы можно было ставить префикс URN схемы перед фактическими путями и ограничивать их :. Таким образом, в этом представлении emails.type и urn:ietf:params:scim:schemas:core:2.0:User:emails.type являются фактическими эквивалентами. Обратите внимание, что URN схемы содержит точки (.) в части 2.0. Это создает дополнительную сложность, поскольку теперь вы не можете просто ограничить текст . и надеяться получить все правильные токены. Я использую структуру данных Trie для записи всех URN схемы как зарезервированные слова. Всякий раз, когда я начинаю новый сегмент в пути, я пытаюсь сопоставить его в Trie, а не полагаться исключительно на . для завершения сегмента.

Надеюсь, это поможет вашей работе.

Взгляните на scim2-filter-parser: https://github.com/15five/scim2-filter-parser

Это библиотека, в основном используемая авторами библиотеки django-scim2: https://github.com/15five/django-scim2

Он полагается на объекты AST Python, но я думаю, вы должны извлечь из этого некоторые выводы.