Комментарии 6
Простите, я не очень понимаю, что именно вы предлагаете. Может потому что я не знаком с Swift.
Вы хотите валидировать ответ сервера?
Если от сервера пришёл ответ, то это либо то, что мы просили, либо сообщение об ошибке. Как ответ сервера может быть невалидным?
Почему клиент решает, какой ответ сервера корректный, а какой нет?
А главное — зачем для этого схема?
Если мы являемся разработчиком сервера и клиента, то у нас вероятно общая codebase между сервером и клиентом. Мы будем проверять, что эти классы правильно сериализуются и десериализуются?
Вы хотите валидировать ответ сервера?
Если от сервера пришёл ответ, то это либо то, что мы просили, либо сообщение об ошибке. Как ответ сервера может быть невалидным?
Почему клиент решает, какой ответ сервера корректный, а какой нет?
А главное — зачем для этого схема?
Если мы являемся разработчиком сервера и клиента, то у нас вероятно общая codebase между сервером и клиентом. Мы будем проверять, что эти классы правильно сериализуются и десериализуются?
Серверные разработчики могут изменить API таким образом, что его обработка приведет к крешу приложения. Если клиент пишется на готовом API — такая ситуация никогда не возникает. Но вот когда API пишется одновременно с клиентом — такая ситуация возникает сплошь и рядом (заменили поле id на ident). Но даже уже существующее API может вызвать проблему, если, вдруг, отправит вместо int тип double или string. Для языков с нестрогой типизацией это обычное явление.
Опять из REST-а кто-то пытается вернуться в SOAP. В REST специфицировать нужно не запросы (они уже специфицированы в HTTP, там выделено строго ограниченное количество глаголов и кодов ошибок для взаимодействия с ресурсами), а сами ресурсы (их отношения с другими ресурсами). Делается это согласно HATEOAS в каждом возвращаемом ресурсе с помощью HAL, а не отдельной схемой, как было принято в WSDL.
HATEOAS и HAL это частные реализации HTTP протокола. Нет нужды подменять ими REST. REST/RESTful повсеместно используется мобильными разработчиками. Поскольку, как правило, мобильный API ограничивается GET и POST запросами, то в тексте упоминается именно REST, а не RESTful, хотя этот факт ни на что не влияет. Кроме того, Вы подменяете HTTP статусы кодами ошибок REST — последние нигде не определены стандартом, и могут меняться разработчиками в широких пределах.
HTTP и HAL — это частная реализация протокола и языка описания ресурсов в парадигме (архитектуре, подходе) REST. Не называйте REST-ом «мобильный API, ограниченным запросами GET и POST». Вы запутались в аббревиатурах и терминах, сочиняя их смысл на ходу.
То, что вы описываете, называется RPC, это противоположный REST-у подход. И в RPC over HTTP уже давно придуманы стандарты контрактов (попробуйте SOAP или XML-RPC).
То, что вы описываете, называется RPC, это противоположный REST-у подход. И в RPC over HTTP уже давно придуманы стандарты контрактов (попробуйте SOAP или XML-RPC).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт использования контрактов при вызовах REST API