контракт api что это
Контракт api что это
Разница между Виртуальной машиной и Контейнером
Примеры решений контейнеризации
API = application programming interface = опубликованный программный интерфейс компонента/системы, позволяющий другим компонентам/системам получать доступ к какой-либо функции.
CDC (Consumer Driven Contract) = контракт потребителя сервиса.
Представляет из себя соглашение между сервисом-поставщиком и сервисом-потребителем в том, что
сервис-поставщик обязуется уметь принимать на вход от сервиса-потребителя определённую структуру данных определённых типов, сериализованную JSON/XML/binary/.
и гарантирует возвращать в ответ определённую структуру данных определённых типов, также сериализованную.
CDC фокусируется на поведении и данных, которые важны Потребителю, т.е. требования исходят от Потребителя: мне нужно вот это.
Метод трёх точек (3-point estimation)
Метод для расчёта временных затрат в проектах с уникальными задачами в условиях неопределённости и при наличии нескольких типов рисков. Используется в IT достаточно широко.
Для того, чтобы начать применять этот метод, нужно проанализировать предмет доработки и описание реализации. Попытаться провести аналогии с ранее выполненными задачами с похожим скоупом. Определить риски и описать мероприятия по устранению этих рисков (что делаем, если сработал тот или иной риск).
Как видим, суть метода сводится к тому, что мы предполагаем, что с вероятностью 0.8 всё пойдёт так, как было и ранее в подобных случаях.
Кастомный метод для T-Shape оценки «размера» задачи
Что делаем: оцениваем задачи таким образом, некоторое время накапливаем статистику по времени выполнения оценённых таким образом задач, а далее при планировании мы уже на этапе такой оценки будем знать, что задача L скорее всего будет выполняться за X дней и т.п.
Потенциал для совершенствования: если суммируются несколько признаков одного уровня (например, объекты доработки), то оценка по этому признаку уходит на уровень выше.
Объектно-ориентиированное программирование (ООП) = методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования/
Разработка REST API — что такое Contract First?
Это третья статья из серии статей про REST API:
При разработке хорошего API REST важно иметь отличные микросервисы. Подход Contract First поможет вам разработать хороший контракт до его реализации. Однако это не так просто!
Вы изучите
Понятие веб-сервисов
Есть несколько видов веб-сервисов, среди которых REST и SOAP. Для каждого сервиса есть:
Contract First подход
При подходе «Contract First» (контракт сначала) вы сначала определяете контракт, а затем внедряете сервис. Давайте рассмотрим пример.
Давайте сначала рассмотрим случай использования WSDL — языка определения веб-сервисов. Вот пример использования:
WSDL обычно используется с веб-сервисами SOAP/XML. В таком случае вы обычно определяете:
Что подразумевается под контрактом?
Когда мы начинаем с заключения договора, мы определяем WSDL, а затем делимся им с нашим потребителем. Все это может произойти еще до того, как мы внедрим сервис и сделаем его доступным.
Контракт сообщает потребителю, каким ожидается обмен запросами и ответами. Как только договор заключен, поставщик услуг может работать над предоставлением услуги, соответствующей договору. Потребитель услуг может работать над разработкой приложения для его использования.
Преимущества подхода Contract First
Команды могут разрабатывать параллельно
Поскольку кодирование происходит на основе контракта, поставщики услуг и группы потребителей услуг четко понимают подход и детали коммуникации. Следовательно, разработка может происходить одновременно.
Команды знают, что ожидать
Поскольку кодирование происходит на основе контракта, команды производителей и потребителей имеют представление об ожиданиях друг друга. В результате, если межгрупповое тестирование невозможно из-за разных темпов разработки, программное обеспечение-заглушка может использоваться для моделирования над поведения другой стороны на основе контракта.
Кроссплатформенная совместимость
Поскольку параметры сервиса зависят только от контракта, фактическая структура программного обеспечения, используемая для разработки сервиса, не имеет большого значения. Поставщик услуг и потребитель услуг могут использовать разные технологии.
Позволяет повторно использовать схемы
Схемы, которые используются для определения договора на услугу, хорошо определены в WSDL. Следовательно, если части служб повторяются в других службах, то соответствующие схемы также можно использовать повторно.
Недостатки подхода Contract First
Требуется дополнительные начальные затраты
Большая часть этих затрат будет сосредоточена вокруг соглашения об обслуживании. Вы должны убедиться, что договор четко определен и не меняется очень часто.
Механизм для обновления контракта и обмена
В течение срока пользования сервиса, если вы обновляете договор, это влияет на все другие заинтересованные стороны. Следовательно, должен существовать надлежащий механизм для передачи изменений различным потребителям.
По этому вопросу имеется авторское видео.
Резюме
В этой статье мы обсудили подход Contract First в контексте веб-сервисов.
Разработка REST API — что такое Code First подход?
Это четвертая статья в серии статей по REST API:
Разработка хорошего REST API важна для того, чтобы иметь хорошие микросервисы. Подход Code-First фокусируется на генерации контракта из кода. Это наилучший из возможных подходов?
Вы изучите
Что такое Code-First подход?
Всякий раз, когда вы разрабатываете сервис, такой как REST API или SOAP API, вы можете выбрать один из двух подходов:
Spring Boot Code First пример REST API
Мы разрабатываем RESTful веб-сервис, используя Spring Boot Framework для генерации API. Например, в API retrieveAllUsers () мы открываем URI «/users» и
возвращаем всех пользователей (ресурс /users),
вызывая метод сервиса.
Когда мы переходим на этот URL, мы возвращаем всех пользователей:
Аналогичным образом определены и другие сервисные методы, каждый из которых имеет свой собственный URI. В этом примере мы берем код и генерируем из него документацию. В этой документации указано, как пользователь может использовать сервис. Для этого мы используем формат документации Swagger:
Swagger позволяет нам генерировать документацию из кода. Например, вот что Swagger генерирует для запроса на получение всех пользователей:
Он выводит тип получаемого нами ответного сообщения и сопровождающий его статус ответа. Вы даже можете вызвать этот сервис из Swagger получить ответ:
Вы также можете отправить запрос POST в «/users«:
Swagger сообщит нам, как структурировать сообщение запроса и указать внутри него отдельные форматы полей. Он также сообщит вам тип ответа, который вы получите, вместе с кодом ответа. То, что Swagger генерирует из кода, называется контрактом.
Преимущества Code First
Основные преимущества этого подхода:
Недостатки Code First
Недостатки этого подхода заключаются в следующем:
Нет параллельной разработки
Производитель услуг и потребители услуг не могут разрабатывать параллельно. Сначала необходимо разработать сервис, затем сгенерировать контракт, и только после этого можно написать код потребителя, который будет придерживаться контракта. Без понимания контракта потребитель не может быть разработан.
Нет цели для команд
Поскольку договор не может быть известен до того, как сервис будет разработан, не существует цели для различных заинтересованных сторон в разработке. Следовательно, есть все шансы, что направления будут отклоняться, и будут внесены ненужные изменения, что приведет к напрасной трате усилий.
Нет кроссплатформенной совместимости
На некоторых старых платформах не так просто сгенерировать контракт из кода. В результате этого для сгенерированных контрактов довольно часто возникает несовместимость между платформами.
По этому вопросу имеется авторское видео.
Резюме
В этой статье мы исследовали Code First подход построения REST API. Несмотря на то, что подход, основанный на коде, эффективен с точки зрения разработчика, он сталкивается с серьезными проблемами, когда речь идет о совместной разработке поставщика и потребителя.
WG Contract API: zoo of services
С ростом количества компонентов в программной системе, обычно растёт и количество людей принимающих участие в её разработке. Как следствие, для сохранения темпов разработки и простоты сопровождения, подходы к организации API должны стать предметом особого внимания.
Если хотите познакомиться поближе с тем как команда Wargaming Platform справляется со сложностью системы из более чем сотни взаимодействующих друг с другом web-сервисов, то добро пожаловать под кат.
Всем привет! Меня зовут Валентин и я инженер на “Платформе” в компании Wargaming. Для тех, кто не знает что такое платформа и чем она занимается, я оставлю тут ссылку на недавнюю публикацию одного из моих коллег — max_posedon
На данный момент я работаю в компании уже более пяти лет и частично застал период активного роста World of Tanks. Чтобы раскрыть проблематику, поднимаемую в данной статье, мне необходимо начать с краткого экскурса в историю Wargaming Platform.
Немного истории
Рост популярности “танков” оказался лавинообразным, и как это обычно бывает в таких случаях, инфраструктура вокруг игры стала стремительно развиваться. В результате игра очень быстро обросла различными web-сервисами, и на момент моего присоединения к команде их счет уже шел на десятки (сейчас, к слову, более 100 платформенных компонентов работают и приносят пользу компании).
Шло время, выходили новые игры, и разобраться в хитросплетениях интеграций между web-сервисами стало уже не просто. Ситуация только обострилась когда к разработке платформы присоединились команды из других офисов Wargaming. Разработка стала распределенной, со всеми вытекающими в виде расстояния, часовых поясов и языкового барьера. А сервисов стало еще больше. Найти человека, который хорошо бы понимал, как устроена платформа в целом, стало не так просто. Информацию часто приходилось собирать по частям из разных источников.
Интерфейсы различных web-сервисов могли сильно отличаться друг от друга в стилистическом исполнении, что делало процесс интеграции с платформой еще более сложной задачей. А прямые межкомпонентные зависимости снижали гибкость разработки тем, что осложняли декомпозицию функциональности внутри платформы. Что еще хуже, игры — клиенты платформы — хорошо знали нашу топологию, в виду того что им приходилось интегрироваться с каждым сервисом платформы напрямую. Это давало им возможность, используя горизонтальные связи, лоббировать реализацию тех или иных доработок напрямую в компоненте, с которым они интегрированы. Это приводило к появлению дублирующейся функциональности в различных компонентах платформы, а также к невозможности распространить уже существующую функциональность на другие игры. Стало очевидно, что продолжать строить платформу вокруг каждой конкретной игры, — это тупиковая ветвь развития. Нам были необходимы технические и организационные изменения, в результате которых мы смогли бы взять под контроль рост сложности быстро растущей системы и сделать всю функциональность платформы пригодной для использования любой игрой.
На этом я хочу закончить исторический экскурс и, наконец, рассказать об одном из наших технических решений, которое помогает удерживать под контролем сложность, вызванную постоянно растущим количеством сервисов. Кроме того оно снижает затраты на разработку новой функциональности и существенно упрощает интеграцию с платформой.
Знакомьтесь, Contract API
Внутри платформы мы называем его Contract API. По своей сути это интеграционный фреймворк, представленный комплектом документации и клиентскими библиотеками под каждую технологию из нашего стека (Erlang/Elixir, Java/Scala, Python). Разрабатывается он, в первую очередь, для того чтобы упростить интеграцию платформенных компонентов друг с другом. Во вторую, чтобы помочь нам решить ряд следующих проблем:
Стилистические различия программных интерфейсов
По моему мнению, данная проблема возникла в результате сочетания нескольких факторов:
С тех пор каждая новая бизнес функция в нашем контрактном API должна быть описана в специальном формате и пройти через пулл реквест с обязательным ревью. Другого способа опубликовать новый API в Contract API не существует. В этом же репозитории мы определили справочник бизнес-специфичных сущностей и предложили разработчикам контрактов переиспользовать их, вместо того чтобы описывать эти сущности самостоятельно.
Так мы получили концептуально целостный API платформы, который выглядел как единый продукт, несмотря на то что в действительности был реализован на множестве платформенных компонентов с использованием различных технологических стеков.
Наличие прямых межкомпонентных зависимостей
Эта наша проблема проявляла себя в том, что от каждого платформенного компонента требовалось знать о том, кто конкретно обслуживает необходимую ему функциональность.
И дело было даже не в сложности поддержки этого справочника в актуальном состоянии, а в том, что прямые зависимости существенно осложняли миграцию бизнес-функциональности с одного компонента платформы на другой. Особенно остро проблема встала когда мы начали декомпозицию своих монолитов на компоненты меньшего размера. Оказалось, что убедить клиента заменить работающую интеграцию с какой-либо функциональностью на такую же с точки зрения бизнеса, но другую с технической точки зрения, довольно не тривиальная менеджерская задача. Клиент просто не видит в этом смысла, так как у него и так всё прекрасно работает. В результате писались дурно пахнущие слои обратной совместимости, которые только усложняли поддержку платформы и плохо сказывались на качестве обслуживания. А раз уж мы и так собрались стандартизировать платформенный API, то необходимо было попутно решить и эту проблему.
Перед нами встал выбор из нескольких вариантов. Из них мы особенно тщательно рассматривали:
Так, топологически, платформа начала превращаться из графа с беспорядочной связностью в звезду. А платформенные компоненты инвертировали свои зависимости и получили возможность взаимодействовать друг с другом исключительно через контракты, зарегистрированные в централизованном хранилище, без необходимости знать о том, кто конкретно реализует тот или иной контракт. Другими словами, все компоненты внутри платформы получили возможность взаимодействовать друг с другом, используя единую точку интеграции, что существенно упростило жизнь разработчикам.
Поддержание документации в актуальном состоянии
Проблемы, связанные с нехваткой документации или утратой её актуальности, встречаются практически всегда. И чем выше темпы разработки, тем чаще она проявляется. А постфактум собрать в едином месте и формате все спецификации на API для более чем сотни сервисов в условиях распределенной и многонациональной команды — задача трудновыполнимая.
Разрабатывая Contract API мы ставили перед собой цель решить в том числе и эту проблему. И у нас получилось. Строго определённый формат описания контракта позволил построить процесс, в соответствии с которым сразу после появления нового контракта запускается автоматическая сборка документации. Это дает нам уверенность в том, что наша документация по API всегда актуальна. Этот процесс полностью автоматизирован и не требует никаких усилий со стороны разработки или менеджмента.
Интроспекция и отладка сквозной функциональности
По мере того как мы дробили наши монолиты на компоненты поменьше, вполне закономерно начали возникать сложности с отладкой сквозной функциональности. Если обслуживание бизнес-функции было распределено по нескольким платформенным компонентам, то часто для локализации и отладки проблемы приходилось искать представителей от каждого из компонентов. Что временами было достижимо с трудом, учитывая 11-часовую разницу во времени с некоторыми из наших коллег.
С появлением Contract API, и в частности благодаря брокеру сообщений лежащему в его основе, мы получили возможность получать копии сообщений, задействованных в исполнении бизнес-функции, без побочных эффектов на участников взаимодействия. Для этого даже не обязательно знать, какой из компонентов платформы отвечает за обработку того или иного контракта. А уже после локализации проблемы мы можем получить идентификатор поломанного компонента из метаданных проблемного сообщения.
Что еще мы разработали поверх Contract API
Помимо основного своего назначения и решения вышеизложенных проблем, Contract API позволил нам реализовать ряд полезных сервисов.
Шлюз для доступа к платформенной функциональности
Стандартизация API в виде контрактов позволила нам разработать единую точку доступа к платформенной функциональности через HTTP. Причем при появлении новой функциональности (контрактов) у нас нет необходимости как-либо модифицировать эту точку доступа. Она совместима наперед со всеми будущими контрактами. Это позволяет работать с платформой как с единым продуктом используя привычный многим HTTP интерфейс.
Сервис массовых операций
Любой контракт может быть запущен в рамках массовой операции, с возможностью отслеживания её статуса и последующего получения отчета о результатах этой операции. Этот сервис, точно так же как и предыдущий, совместим со всеми будущими контрактами наперёд.
Единая обработка платформенных ошибок
Протокол Contract API стандартизирует в том числе и ошибки. Это позволило нам реализовать перехватчик ошибок, который анализирует их серьезность и оповещает систему мониторинга о потенциальных проблемах на платформенных компонентах. А в перспективе сможет самостоятельно принять решение об открытии бага на платформенный компонент. Перехватчик ошибок вылавливает их напрямую из брокера сообщений и ничего не знает о назначении того или иного контракта или ошибки, действуя лишь на основе метаинформации. Это позволяет ему так же, как и всем описанным в этом разделе сервисам, быть наперёд совместимыми со всеми будущими контрактами.
Автоматическая генерация пользовательских интерфейсов
Строго формализованные контракты позволяют в автоматическом режиме строить компоненты пользовательского интерфейса. Мы разработали сервис, который позволяет генерировать административный интерфейс на основе коллекции контрактов, а затем встроить этот интерфейс в любой из наших платформенных инструментов. Таким образом, те админки которые мы раньше писали руками, теперь можно генерировать (правда пока только частично) в автоматическом режиме.
Протоколирование платформенных взаимодействий
Этот компонент на данный момент еще не реализован и находится на стадии проработки. Но в перспективе он позволит “на лету” включать и выключать логирование любой бизнес-функции в платформе, извлекая эту информацию напрямую из брокера сообщений, без каких-либо побочных эффектов, негативно влияющих на взаимодействующие компоненты.
Основное назначение Contract API
Но всё же основное назначение Contract API — снижать издержки на интеграцию платформенных компонентов.
Разработчики абстрагированы от транспортного уровня библиотеками, которые мы разработали под каждый из наших технологических стеков. Это дает нам некоторое поле для маневра на тот случай, если придётся менять брокер сообщений или вовсе переходить на взаимодействие типа “точка-точка”. Внешний интерфейс библиотеки сохранится без изменений.
Библиотека под капотом формирует сообщение по определённым правилам и отправляет его в брокер, после чего, дождавшись ответного сообщения, возвращает результат разработчику. Снаружи это выглядит, как обычный синхронный (или асинхронный, зависит от реализации) запрос. В качестве демонстрации приведу несколько примеров.
Пример вызова контракта с использованием Python
Этот же вызов контракта, но с использованием Elixir
На месте контракта “ban-management.create-ban.v1” может быть любая другая платформенная функциональность, например: “account-management.rename-account.v1” или “notification-center.create-sms-notification.v1”. И вся она будет доступна через эту единую точку интеграции с платформой.
Обзор будет неполным, если не продемонстрировать Contract API с точки зрения серверного разработчика. Рассмотрим ситуацию, в которой разработчику нужно реализовать обработчик для всё того же контракта “ban-management.create-ban.v1”.
Этого кода будет достаточно, чтобы начать обслуживать заданный контракт. Серверная библиотека распакует и проверит параметры запроса на корректность, а затем вызовет обработчик контракта с уже готовыми для обработки параметрами запроса. Таким образом, серверный разработчик защищен библиотекой, которая в случае получения некорректных параметров запроса сама отправит клиенту ошибку валидации и зарегистрирует факт наличия проблемы.
Благодаря тому что под капотом Contract API реализован на основе событий, мы получаем возможность выйти за рамки сценария Запрос/Ответ и реализовать более широкий спектр межсервисных взаимодействий.
Опыт использования контрактов при вызовах REST API
Существуют два непримиримых лагеря разработчиков программного обеспечения: первый — утверждает, что чем больше крешится приложение, тем лучше оно работает. Второй — что программист достаточно умен, чтоб обработать любую нештатную ситуацию. Характерной особенностью первых является обилие директив Asset в кода, вторые же, даже операции сложения помещают в блок try — catch. Причем, оба лагеря называют такого рода подход «Программированием по контракту». Аргументы первых сводятся к статье в википедии, аргументы вторых — к книге «Почувствуй класс» Бертрана Мейера.
В рамках научного исследования было бы правильно рассмотреть все многообразие подходов защитных механизмов программирования, особенно тех, что вынесены в заголовок этой статьи, однако, мне хочется продемонстрировать лишь одну из возможностей, которая тяготеет ко второму лагерю.
Основной посыл таков: Если в приложении возникает исключительная ситуация — то делаем вид, что операцию которая к ней привела вообще не вызывали. Ну, во всяком случае, так оно будет выглядеть с точки зрения пользователя продукта. Кроме того, добавим сюда немаловажное ограничение — речь идет исключительно о клиент-серверном взаимодействии.
Практический аспект таков: Когда от сервера приходит REST ответ который мы не можем обработать в связи с нарушением целостности данных (значения имеют неверные диапазоны, отсутствуют обязательные поля и т. п.) мы просто игнорируем такой вызов, и не пытаемся его распарсить.
Как правило в процессе парсинга нас поджидают неожиданности, поскольку не всё что приходит от сервера заслуживает доверия. Приходится каждый параметр проверять на соответствие типу, принадлежность диапазону, правильности ключа и пр., а это существенно увеличивает код метода парсинга, особенно, если получаемая иерархическая структура имеет множество степеней вложенности и разные типы данных (массивы, словари и т. п.) Попытка провалидизировать каждый из параметров наводит на мысль вынести логику валидации хотя бы в отдельный метод. Это позволит сделать подход несколько более гибким:
Получаем 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 в исходный код проекта будет достаточно добавить следующий класс:
import UIKit
import VVJSONSchemaValidation
private var _schemaName = «»
var schemaName:String <
get <
return _schemaName
>
set(value)
<
_schemaName = value
guard let path = NSBundle.mainBundle().pathForResource(value, ofType: «json») else <
return
>
do
<
if let schemaData = NSData(contentsOfFile:path) <
self.schema = try VVJSONSchema(data: schemaData, baseURI: nil, referenceStorage: nil)
>
>
catch let error as NSError
<
print(«\n»)
print(«===============================================================»)
print(«Schema ‘\(value).json’ didn’t create:\n\(error.localizedDescription)»)
print(«===============================================================»)
print(«\n»)
>
>
>
private var schema:VVJSONSchema?
В классе, в котором получаете ответ от сервера добавляем:
let validator = Validator()
validator.schemaName = «response»
А в методе (блоке) где получаем серверный ответ пишем:
if self.validator.validate(response) <
self.parse(response) //
Вот и все.
Теперь, если со стороны сервера придут данные которые не соответствуют указанной схеме, то механизм парсинга не будет запущен. Вам не нужно описывать в коде логику 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»: