Кратко

  • Проект JMAP Enhanced Result References позволяет выбирать данные из ответа предыдущего метода и подставлять их в свойства, PatchObject и фильтры последующих методов.
  • После выбора значение должно пройти проверку ожидаемого типа без неявного преобразования. Отказ сохраняет свидетельство о несовместимости; coercion создаёт видимость согласия, которого источник не выражал.

Строка "01" могла быть кодом, индексом с ведущим нулём или идентификатором. Число 1 могло означать количество, приоритет или числовой ключ. Их текстовая близость не доказывает взаимозаменяемость.

Тем не менее промежуточный компонент решил «помочь». Он увидел, что следующий фильтр ждёт число, преобразовал строку и передал результат. Типовая проверка стала зелёной, а запрос — выполнимым. Заодно исчез вопрос, на который никто не ответил: кто уполномочил эту интерпретацию?

Именно отказ иногда является самым ценным результатом автоматизации. Он сохраняет границу между тем, что источник сообщил, и тем, что назначение готово принять.

Редакция 02 проекта JMAP Enhanced Result References датирована 21 июня 2026 года и истекает 23 декабря 2026 года. На дату исследования это был активный Internet-Draft рабочей группы JMAP на пути Standards Track, а не финальный RFC, сертификат реализации или показатель внедрения.

Документ расширяет ссылки на результаты из RFC 8620. Методы в одном JMAP-запросе выполняются последовательно. Более поздний вызов указывает предыдущий через resultOf и name, а path выбирает данные из объекта аргументов ответа. Расширение разрешает такие ссылки в свойствах /set, значениях PatchObject и FilterCondition внутри /query. Помимо JSON Pointer сервер может опционально поддерживать JSON Path.

Механизм определяет, как данные перемещаются. Он не должен незаметно определять, что данные означают.

Проверка типа — это сохранение смысла

После разрешения ссылки сервер обязан проверить значение по ожидаемому типу места назначения. Для свойства /set несовместимость приводит к invalidProperties; для фильтра /query — к invalidArguments.

Проект отдельно предупреждает: нельзя превращать строки в числа или логические значения, а сложные объекты — сериализовать в строки только ради прохождения проверки. Нельзя и в обратную сторону приписывать структуру значению, которое её не заявляло.

Это правило защищает не эстетическую чистоту JSON, а доказательную честность. Если источник дал строку, именно строка является наблюдаемым фактом. Число после преобразования — новый вывод. Чтобы такой вывод стал допустимым, нужны явная схема преобразования, область действия, версия правила и ответственный субъект.

Без этих элементов coercion превращает технический компонент в скрытого автора политики. Он не просто ремонтирует упаковку; он решает, какие различия считать несущественными.

Отказ оставляет возможность исправить контракт: изменить источник, выбрать другое поле, использовать назначение правильного типа или ввести контролируемое преобразование на уровне, который понимает домен. Автоматическое приведение удаляет сам сигнал, что такой выбор требовался.

Правильный тип всё равно может быть неправильным значением

Строгая типизация необходима, но недостаточна. Идентификатор почтового ящика может быть корректной строкой и относиться к другой учётной записи. blobId может иметь правильный формат и указывать на закрытое вложение, которое нельзя публиковать в целевом объекте. Логическое значение может быть валидным и происходить из отменённой политики.

Нужно различать три проверки. Тип отвечает за форму. Домен отвечает за принадлежность к аккаунту, tenant или объектному пространству. Авторизация отвечает, может ли этот principal использовать значение для данного эффекта.

Одна зелёная метка скрывает, какой вопрос был решён. Система может честно сказать: «разрешена одна строка». Она не должна сокращать это до «выбран правильный почтовый ящик» без доменного свидетельства.

То же касается происхождения. resultOf, имя метода и путь связывают значение с конкретным предыдущим ответом. Это полезная трассировка выполнения. Она не доказывает истинность первичного источника, свежесть ответа или право источника управлять последующим действием.

Сильная запись сохраняет узкую формулировку каждого слоя, а не складывает их в одно обещание.

Кардинальность не разрешает неоднозначность за нас

JSON Path возвращает список из нуля, одного или нескольких узлов. Проект задаёт правила его преобразования. Для примитивного или одиночного объекта один узел становится значением, ноль — null, несколько — ошибкой invalidResultReference. Для массива ноль становится [], а узлы сохраняются в порядке RFC 9535. Для map ноль становится {}, и допустим только один подходящий объект.

Несколько результатов для одиночного назначения — не повод взять первый. Порядок дерева или обхода не равен приоритету. Если бизнес-правило требует новейший, наиболее доверенный или вручную одобренный объект, правило должно быть явным и проверяемым.

Ноль также не означает безопасное отсутствие действия. null может очистить существующее свойство. Пустой массив может означать отсутствие кандидатов или команду удалить всех участников. Пустая map может означать отсутствие настроек или их полную замену.

JSON Pointer добавляет тонкость: отсутствующий точный путь без wildcard — ошибка, тогда как wildcard без совпадений может дать типизированную пустоту. Замена точного указателя на более широкий селектор ради меньшего числа отказов способна превратить отсутствие доказательства в инструкцию изменить состояние.

Для каждого важного назначения нужна явная политика нулевого и множественного результата. Resolver не должен угадывать её, как не должен угадывать преобразование типов.

Тонкий промежуточный слой имеет право не знать

Проект допускает синтаксический промежуточный слой, который применяет JSON Pointer или JSON Path к непрозрачному JSON, не понимая типов методов, свойств и их семантики. Затем слой исполнения метода интерпретирует результат по определению назначения.

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

Дисциплина тонкого слоя Хэн Лу полезна именно здесь. Участие в координации не создаёт мандат. Resolver переносит JSON; валидатор проверяет форму; уполномоченный доменный слой решает, что значение означает и где его можно использовать.

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

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

Фильтр может быть точным в неправильном пространстве

В FilterCondition можно поместить ссылку через имя свойства с префиксом #. Вложенные условия обрабатываются рекурсивно. Неразрешимая ссылка отклоняет весь запрос с invalidResultReference; одновременное наличие обычного свойства и его версии с # даёт invalidArguments.

Так запрос может получить ID почтового ящика из предыдущего ответа. Даже без coercion строка может принадлежать другой учётной записи. Синтаксически точный фильтр тогда ограничит поиск неправильным доменом.

Наблюдаемость должна связать две стадии: стоимость и результат выбора, а затем масштаб запроса, который он запустил. Дешёвое извлечение одной строки способно открыть широкий поиск или раскрыть существование данных в другом контексте.

Возможность urn:ietf:params:jmap:refplus доказывает поддержку механизма; флаг jsonPath — поддержку языка. Они не дают полномочия соединять любую найденную строку с любым фильтром.

Межконтекстная передача требует отдельного решения

Предыдущий Email/get может вернуть идентификатор закрытого вложения. Последующий /set может вставить его в объект с более широкой аудиторией. Principal иногда вправе читать письмо и редактировать объект, но не вправе публиковать вложение через этот объект.

Чтение источника и запись назначения — локальные разрешения. Передача между ними — третье действие. Административные и сервисные аккаунты особенно опасны: широкая видимость на одном этапе сочетается с другим кругом читателей на следующем.

Проект обращает внимание на утечку между контекстами и необходимость журналировать производные данные. Полезное решение сравнивает видимость источника с аудиторией назначения и сохраняет причину разрешения перехода.

Типовая совместимость не добавляет этой причины. Более того, coercion может скрыть именно тот разрыв, который заставил бы систему остановиться до передачи.

Кэш должен помнить контекст и время

Результат выражения удобно кэшировать: одинаковый ответ и путь часто дают одинаковое значение. Но право использовать его зависит от пользователя, аккаунта и состояния доступа.

Если после первого вычисления человека исключили из закрытой группы, строка и путь могут остаться прежними. Устаревает не значение, а основание его применять. Проект требует не делить кэш между пользователями или контекстами безопасности и инвалидировать его при изменении ACL.

Надёжный ключ связывает principal, аккаунт, релевантные полномочия и эпоху политики. Для чувствительной передачи он включает назначение. Журнал различает новое вычисление и повторное использование.

Разница во времени ответа тоже может раскрыть существование пути в другом контексте. Изоляция должна защищать не только содержимое, но и наблюдаемое поведение.

Кэш-хит говорит, что ключ найден. Качество доказательства зависит от того, какие факты вошли в ключ.

Выразительность JSONPath требует пределов

JSON Pointer идёт по точному маршруту. JSON Path применяет фильтры, wildcard и рекурсивный спуск. Короткое выражение на большом ответе может создать огромный список узлов. Цепочки ссылок и вложенное копирование увеличивают расход.

Серверу нужны ограничения сложности, времени, размера списка, числа ссылок, глубины и суммарной стоимости. При превышении следует явно отказать, а не обрезать результат. Обрезка меняет доказательство и способна превратить множественность в ложную единственность.

Парсер JSON Path — зависимость безопасности. Ему нужны обновления, изоляция и испытания враждебными выражениями. Рост ошибок бюджета может означать атаку, увеличение исходного ответа или слишком широкое клиентское выражение.

Автоматическое повышение лимита так же опасно, как автоматический coercion: оно убирает отказ, не решая вопрос о намерении и масштабе.

Отказ должен остаться видимым

Работающий код должен испытать ноль, один и несколько узлов для каждого типа назначения; отсутствующий точный pointer и пустой wildcard; несовместимые типы без преобразования; одинаковые по форме ID разных аккаунтов; смену ACL; дорогие выражения и перенос приватных данных.

Особенно важно проверять клиента после отказа. Если он присылает первый элемент, уже преобразованное число или вручную урезанный массив, это не повтор транспорта. Он изменил правило принятия решения. Такая смена требует отдельной причины и владельца.

Строка "01" не была плохими данными. Она была данными, не соответствовавшими числовому контракту назначения. Отказ сохранил бы этот факт. Преобразование сделало систему удобнее и доказательство слабее. Расширенные ссылки JMAP полезны тогда, когда ускоряют поток данных, не ускоряя исчезновение несогласия.

Источники