Существуют два непримиримых лагеря разработчиков программного обеспечения: первый — утверждает, что чем больше крешится приложение, тем лучше оно работает. Второй — что программист достаточно умен, чтоб обработать любую нештатную ситуацию. Характерной особенностью первых является обилие директив Asset в кода, вторые же, даже операции сложения помещают в блок try — catch. Причем, оба лагеря называют такого рода подход «Программированием по контракту». Аргументы первых сводятся к статье в википедии, аргументы вторых — к книге «Почувствуй класс» Бертрана Мейера.

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

Основной посыл таков: Если в приложении возникает исключительная ситуация — то делаем вид, что операцию которая к ней привела вообще не вызывали. Ну, во всяком случае, так оно будет выглядеть с точки зрения пользователя продукта. Кроме того, добавим сюда немаловажное ограничение — речь идет исключительно о клиент-серверном взаимодействии.

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

Справедливости ради нужно сказать, что существуют библиотеки, которые производят документа-объектные преобразования по полученному JSON/XML объекту. Обратной стороной их медали является то, что, как правило, такой подход делает нежизнеспособным использование модели CoreData, поскольку, требуется наличие двух модельных логик: документа-объектных преобразований (JSON -> Binary Objects) и объектно-реляционных преобразований (Binary Objects -> CoreData Entities), поддерживать обе логики, и делать синхронизацию между ними — не хочется никому.

Обычный процесс клиент серверного взаимодействия следующий:

1. Формируем запрос к серверу с имеющимися параметрами (request)
2. Делаем запрос по заданному url
3. Получаем ответ (response)
4. Извлекаем из ответа данные (parsing)

Как правило в процессе парсинга нас поджидают неожиданности, поскольку не всё что приходит от сервера заслуживает доверия. Приходится каждый параметр проверять на соответствие типу, принадлежность диапазону, правильности ключа и пр., а это существенно увеличивает код метода парсинга, особенно, если получаемая иерархическая структура имеет множество степеней вложенности и разные типы данных (массивы, словари и т. п.) Попытка провалидизировать каждый из параметров наводит на мысль вынести логику валидации хотя бы в отдельный метод. Это позволит сделать подход несколько более гибким:
Получаем response. Валидируем response. Если валидация была успешной — делаем парсинг, иначе — ничего не делаем (или выдаем уведомление серверу/пользователю).
Не секрет, что в основе REST взаимодействия лежит JSON. Те кто предпочитают использовать XML, как правило, имеют свои механизмы решения аналогичных проблем. К примеру, WCF контролирует типы на этапе создания прокси-классов. Увы, пользователи JSON этого сахара лишены, и все приходится делать вручную. В результате, код проверки валидности объекта, чаще всего становится столь же большим, как и код парсинга.

Помочь в решении этой ситуации позволяет использование механизма JSON схем. Формат весьма неплохо стандартизирован и имеет избыточное описание: json-schema.org, кроме того, имеется множество online инструментов, позволяющих формировать схемы по введенному JSON: jsonschema.net/#

Попробуем рассмотреть практический пример для языка программирования Swift.
При беглом поиске удалось найти публичный сервис, который возвращает JSON ответ на простой GET запрос: httpbin.org/get?myFirstParam=myFirstValue&mySecondParam=MySecondValue

Ответ будет примерно следующим:


Ответ не содержит никакой практически-полезной информации, но позволяет отладить процесс взаимодействия. В ответе содержится строка GET запроса, и параметры, которые были переданы, а так же, некоторые сведения о браузере, через который был произведен запрос. При осуществлении запроса с симулятора или реального устройства результат ответа может быть немного другим. Вместе с тем, он обязан быть подчинен определенной схеме, которую можно извлечь, при помощи online инструментов (http://jsonschema.net/#/ и подобных).

В левой панели установим все галочки. Переключатель опции «Arrays» рекомендую поставить в значение «Single schema (list validation)» (особенности языка Swift).


Скопируем браузерный ответ в верхнее левое окно, и убедимся, что мы разместили валидный JSON. Это будет ясно по надписи «Well done! You provided valid JSON.» на зеленом фоне непосредственно под окном. К сожалению, при выводе ответа в XCode консоль даже при помощи оператора print() не соблюдаются требования формата. Если Вы все же решитесь брать текст ответа из консоли, Вам придется заменить все символы равенства «=» на двоеточие «:», и все имена полей взять в парные кавычки.


После нажатия на кнопку Generate Schema мы получаем в правом окне довольно длинную схему для такого небольшого запроса:



В принципе, схему можно сократить, не устанавливая галочки, и приведя переключатель «Array» в состояние «Single empty schema», но так мы лишимся возможности использовать некоторые плюшки совместного использования схемы и языка Swift.

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

Создайте файл с именем response.json и добавьте его в проект.
Если Вы используете Cocoapods добавьте строку
pod ‘VVJSONSchemaValidation' в Ваш Podfile. Если Cocoapods Вы не испоьзуете, то придется обратится непосредственно к GitHub репозиторию Влада Волошина: github.com/vlas-voloshin/JSONSchemaValidation

После обновления Cocoapods в исходный код проекта будет достаточно добавить следующий класс:



В классе, в котором получаете ответ от сервера добавляем:

let validator = Validator()
validator.schemaName = "response"


А в методе (блоке) где получаем серверный ответ пишем:

if self.validator.validate(response) {
self.parse(response) // <— это метод извлечения данных их JSON
}


Вот и все.
Теперь, если со стороны сервера придут данные которые не соответствуют указанной схеме, то механизм парсинга не будет запущен. Вам не нужно описывать в коде логику JSON ответа, только для того, чтоб понять, не допущена ли там какая-то ошибка. Т. е. если он верный — можно смело парсить. Конечно, такой код не защищает Вас на 100%, но 99.9% ошибочных ответов будет отсеяно. Опыт показывает, что при ручном программировании логики, количество ошибочных ответов приводящих к крешу системы отсеивается только в 68,2%.

Дополнительными плюшками от такого подхода можно выделить то, что можно указать дефолтные значения в прямо в схеме:
"default": «193.105.7.55" можно заменить на "default": "127.0.0.1",


А в «enum» привести перечень тех значений которые допустимы для объекта модели данных. В моем случае, это Optional String (String?), т. е. строка которая потенциально может содержать либо nil, либо «193.105.7.55»:


Очень легко перейти к развитию этой концепции:

1. Схемы могут создаваться разработчиками, которые разрабатывают REST API, и в готовом виде интегрироваться в приложение. В случае ошибок будет всегда один ответственный за нарушение целостности данных.
2. В случае, если валидация данных не проходит, на сторону сервера передается название схемы, запрос и ответ сервера. Это позволит оперативно отследить и корректировать работу API на стороне back-end