Многие сервисы и приложения (особенно веб-сервисы) принимают древовидные данные. Например, такую форму имеют данные, поступающие через JSON-PRC, JSON-REST, PHP-GET/POST. Естественно, появляется задача валидировать их структуру. Существует много вариантов решения этой задачи, начиная от нагромождения if-ов в контроллерах и заканчивая классами, реализующими валидацию по разнообразным конфигурациям. Чаще всего для решения этой задачи требуется рекурсивный валидатор, работающий со схемами данных, описанными по определённому стандарту. Одним из таких стандартов является JSON-Schema, рассмотрим его поближе.
Или сказ о том, как разработка JSON валидатора превратилась в очередной JSON binding
Пока нормальные разработчики пишут приложения я изобретаю велосипеды.
Наверное многие разработчики сталкивались с ситуацией, когда мобильное приложение разрабатывается параллельно с бэкэндом. При этом частенько структуры данных, приходящие в ответ на запрос с сервера, могут меняться. Например, на стороне бэкэнда решат поменять именование одного из ключиков JSON-а, забыв предупредить о этом мобильную команду. Я уже не говорю про ситуации, когда CamelCase нотацию «внезапно» решили поменять на underscore или наоборот. Вы можете сказать, что налицо плохая организация процесса и недостаток общения команд, и будете абсолютно правы. Но когда приложение на смартфоне заказчика перестает работать на демо все взгляды устремляются на мобильщиков.
Справочный API 2ГИС разрабатывается уже 4 года. Появилось около 40 методов, которые возвращают достаточно крупные и иерархически сложные структуры в формате JSON и XML. Совсем недавно я решил поделиться накопленным опытом и выступить на конференции DevConf.
Одна из тем доклада вызвала наибольший интерес у участников — это использование JSON-Schema при тестировании формата выдачи API. В этой статье я расскажу, какие задачи решает этот подход, какие имеет ограничения, что вы получаете из коробки, а что идёт бонусом. Поехали!
В данной статье описывается стандарт JSON Schema и его использование для проверки соответствия заданному формату на языке C++ средствами библиотеки valijson.
Немного истории
Для начала вспомним, что привело к повсеместному вытеснению JSON-ом XML-а и что в этом было плохого. XML изначально создавался как метаязыкразметки документов, позволяя использовать унифицированный код парсера и валидатора документов. Будучи первым стандартом такого рода, да еще и пришедшимся на период бурного внедрения цифровых корпоративных информационных систем, XML послужил основой для бесчисленного множества стандартов сериализации данных и протоколов взаимодействия, т.е. хранения и передачи структурированных данных. Тогда как создавался он прежде всего для разметки документов.
Что же такое декларативное программирование? Википедия подскажет нам:
Декларати́вное программи́рование — это парадигма программирования, в которой задается спецификация решения задачи, то есть описывается, что представляет собой проблема и ожидаемый результат.
Далее в статье пойдет речь о том, как использовать данную парадигму в современном web-программировании. В частности, я хотел бы затронуть вопрос о валидации/верификации входных данных для веб сервисов. Примеры будут на php, так как это язык мне наиболее близок в профессиональном плане.
Запускаем сегодня наш переделанный курс «Разработчик JavaScript» и вспомнили, что у нас есть ещё один открытый урок по нему же. На нём разбирали основные идеи JSON Schema, синтаксис, определяемый в спецификации, ну и для чего вообще стоит использовать эту технологию.
Уважаемый хабрачитатель, хочу поделиться с тобой опытом в выборе и использовании генераторов форм для Vue.js.
Введение
Пожалуй, известно каждому, что любой выбор начинается с фиксации целей, постановки задач и формирования списка требований к объектам выбора. Данная статья описывает функциональные возможности готовых решений и не призвана ответить на все вопросы в рамках данной темы.
Если вы только погружаетесь в эту предметную область, то первое, что вам необходимо сделать — это оценить применимость данного подхода к вашей разработке. Можно выделить следующие ситуации, когда этот подход оправдает себя:
Приложение имеет множество однотипных форм, где декомпозиция компонентов не оказывает должного эффекта, а использование copy & paste только ухудшает поддерживаемость;
Приложение очень динамично развивается и требуется экономить время на реализации каждой новой фичи продукта в ущерб UX (User eXperience);
Приложение находится на стадии прототипирования и большая часть функциональности будет изменена или удалена в ближайшее время.
Далее необходимо определиться со списком требований к библиотеке генератора форм (данный список может отличаться от ваших требований):
Библиотека для Vue.js;
Поддержка Element UI, желательно актуальной версии;
Построение форм из JSON schema, с использованием валидаторов;
Возможность локализации форм, включая ошибки валидации.
Для транспорта данных я почти всегда упаковываю их в JSON. Но вот беда: как правило, библиотеки для парсинга возвращают примитивные типы да объекты с массивами — всё то, что заложено самим форматом. Но что если хочется получить модели сущностей?
