СУХОЙ валидация пользовательского ввода (на стороне клиента, на стороне сервера) с использованием схемы JSON

Как часть обширного тестовый пример, я создаю CMS-подобное приложение на основе ajax, которое обеспечивает CRUD-функциональность для различных типов документов, например: статьи, теги и т. д.

на сервере и на стороне клиента. Я собираюсь использовать JSON. -schema ( http://json-schema.org/ ) как способ сделать проверку ввода пользователя СУХИМ способом (то есть: 1 схема проверки, которая будет использоваться как на сервере, так и на клиенте) сторона, никакого дубликата-кода и все такое). Это кажется отличным, потому что:

• Схема JSON реализована как в JS, так и в Java, поэтому одна схема может теоретически обрабатывать проверку на стороне клиента и на стороне сервера

• все запросы и ответы операций CUD являются JSON (через ajax )

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

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

Итак, было бы хорошей идеей (с точки зрения дизайна / архитектуры) включить дополнительные проверки, подобные описанной выше, в платформу проверки на основе json-схемы на стороне сервера? Было бы это элегантным решением? Или вы бы держали их отдельно? Если нет, то почему и какой другой подход вы бы предложили оставаться СУХИМ в отношении проверки на стороне клиента и на стороне сервера?

Что вы думаете?

Некоторый дополнительный контекст / цели приведенного ниже текстового случая для некоторой справочной информации.

Спасибо, Герт-Ян

Некоторые контекст / цели:

• CMS на основе ajax с использованием подхода REST

• CUD-запросы выполняются через ajax с использованием подхода отдыха (то есть: отображение на POST, PUT, DELETE соответственно). Запросы и ответы выполняются через JSON.

• CMS без форм. Вместо этого используйте редактирование на месте (например, используя Aloha-editor: http://www.aloha-editor.org/

• оставаясь СУХИМ.

  1. Шаблоны: выполняются с помощью шаблонов Mustache на стороне клиента и на стороне сервера. Начальный рендеринг и инкрементный рендеринг через ajax выполняются на основе 1 и того же шаблона. Я хотел пойти на что-то другое, кроме Mustache (потому что у него не хватает выразительной силы), но это работает, по крайней мере, для этого прототипа (см. Предыдущий вопрос. для альтернатив, на которые я все еще ищу ответ: Клиентский язык шаблонов с компилятором Java (DRY шаблоны) )

  2. DRY проверка ввода: как описано выше

Проверка поток (в случае сбоя):

1. пользователь создает / обновляет / удаляет элемент.

2. сбой проверки на клиенте мгновенно дает пользователю обратную связь о том, что нужно исправить (валидатор схемы Javascript JSON будет в идеале возвращать форматированный для пользователя JSON)

3. когда проверка на стороне клиента завершается успешно, операция CUD выполняется перфорированно. rmed с использованием ajax.

4. если проверка на стороне сервера завершилась неудачно, возвращается код состояния 400 (неверный запрос) с Json-объектом, содержащим ошибки проверки, которые обнаруживаются функцией обратного вызова ошибки jquery

    $. Ajax  ({
     ....
     error: function (xhr, status, error) {
     var validationJSON = JSON.parse (xhr.responseText);
     // обрабатываем сбой проверки на стороне сервера
     },
     ....
    });
    

5. JSON-объект, содержащий ошибки проверки на стороне сервера, представляется пользователю (аналогично клиентскому)