Сразу оговорюсь, я мобильный разработчик, а статья предназначена в основном для разработчиков по ту сторону облака — мобильные разработчики обо всем этом уже знают. Последнее веб-приложение я написал много лет назад и, возможно, ошибаюсь в веб-терминологии, возможно, не знаю некоторых последних тенденций в веб-сервисах .
NET, PHP или Java, поэтому не судите слишком строго.
Как любому фронтенд-разработчику, практически в каждом проекте мне приходится сталкиваться с клиент-серверными протоколами — без них я не могу обойтись.
И очень и очень часто приходится работать с плохо продуманной архитектурой.
Также очень часто разработка протокола и архитектуры ложится на плечи веб-разработчика, что не всегда верно — в большинстве случаев ее следует разрабатывать только совместно с теми, кто будет адаптироваться под эту архитектуру.
К сожалению, работая над несколькими десятками проектов за последние три года, мне довелось поучаствовать в планировании этого участка архитектуры всего 3-4 раза - во всех остальных случаях он уже был предоставлен в той или иной степени готовности заказчиком.
клиент. Но насколько лучше мог бы быть мир!
Обработка ошибок
Чаще всего мне попадалось что-то вроде этого:Те.HTTP code 200 (OK) <Эxml version="1.0" encoding="utf-8"?><Body> <Result> <Success>false</Success> <Error>The username or password is incorrect. Please try again.</Error> </Result> <Response> </Response> </Body>
результат обработки запроса содержится в самом отправленном XML, код возврата HTTP — 200, т.е.
ок, данные представлены как обычный RPC. Например, обработка ошибок в протоколе SOAP в 90% случаев реализована аналогичным образом.
В особо сложных случаях, особенно характерных для индийского кода, false может располагаться в различных местах XML, что существенно усложняет парсинг, приводит к переусложнению и доставляет огромную радость скучающему программисту.
Но давайте посмотрим на недостатки такого подхода в принципе.
- Сначала вам нужно проанализировать XML. Это дополнительные данные, передаваемые по сети, дополнительное время процессора, затрачиваемое на парсинг XML, дополнительная оперативная память для хранения текстовых данных.
Все это не так страшно на современных устройствах в зоне Wi-Fi, но даже такие излишества могут иметь значение в метро между станциями в приложении, которое отправляет десятки запросов одновременно (и при таком подходе пустые блоки для обработки ошибок должны быть в каждый запрос, даже успешный).
- Во-вторых, веб-разработчику приходится самому придумывать тексты ошибок.
Очень часто они совершенно непонятны пользователю, потому что… точность формулировок — последнее, о чем думает веб-разработчик при написании сервиса.
Текст ошибки в 90% случаев не согласуется с носителями языка, и последнее, но самое главное — огромное количество мобильных приложений нуждаются в локализации.
В то время как текст ошибки, скорее всего, всегда пишется только на английском языке, поэтому для фронтенд-программиста он абсолютно бесполезен — он не может просто взять и отобразить его.
Как решить проблему?
Протокол HTTP уже много лет имеет возможность добавлять собственные коды ошибок; для этого они просто должны принадлежать диапазону от 512 до 597. Я уверен, что такого количества ошибок будет достаточно, чтобы перекрыть все возможные ошибки в приложении среднего размера.Какие преимущества это дает понятно, но давайте подведем итоги:
- Никакой избыточности.
Передается только HTTP-код в заголовке, тела запроса просто нет.
- На стороне клиента есть всего две ветки кода обработки запроса — успешное выполнение или ошибка выполнения (оба коллбэка уже реализованы «из коробки» в любой библиотеке запросов).
Нет нитей «запрос выполнен успешно, но в теле ответа может быть логическая ошибка».
Ошибка сервера 5xx Серверу не удалось выполнить очевидно действительный запрос.Те.[2] Коды состояния ответа, начинающиеся с цифры «5», обозначают случаи, когда сервер знает, что столкнулся с ошибкой или по какой-либо причине неспособен выполнить запрос.
За исключением ответа на запрос HEAD, сервер должен включать объект, содержащий объяснение ошибочной ситуации, и указывать, является ли это временным или постоянным состоянием.
Аналогично, пользовательские агенты должны отображать пользователю любую включенную сущность.
Эти коды ответа применимы к любому методу запроса.
клиенты должны показать пользователю сообщение, отправленное сервером.
Сразу понятно, что написали американцы.
Россияне, кстати, тупо переведено .
Хотя не будем обобщать — идею использования HTTP-кодов мне подсказал один американец несколько лет назад. В общем, идеология такая: клиент всегда лучше знает, как сообщить об ошибке.
И сервер должен сообщить клиенту об ошибке самым быстрым и экономичным способом.
Привязка к сеансу или cookie.
Такое подключение, скорее всего, происходит, если сначала был создан сайт, а уже потом заказчик решил создать мобильный интерфейс.Хотя работа с переменными сессии и возможна на мобильной стороне, это не является хорошей практикой, т.к.
зачастую нет нормального инструментария для работы с этими инструментами.
Второй, глобальный недостаток – Safari (или любой браузер на Android) не передает свои кукисы и переменные сессии с приложением, что, конечно, правильно с точки зрения безопасности, но приводит к ряду проблем и костылей.
.
Допустим, ваше мобильное приложение реализует только 70% функционала сайта.
Остальные 30% функциональности доступны только в Интернете, а ваше приложение содержит только ссылки на соответствующие веб-страницы.
Также возможно, что эти страницы доступны только авторизованным пользователям.
В результате пользователю, уже зашедшему в мобильный клиент, будет предложено авторизоваться еще раз – на этот раз в неудобной веб-форме, и счастье будет, если после входа пользователь будет перенаправлен в нужный раздел сайта.
Итог: если вы разрабатываете общий протокол, забудьте о таких вещах, как переменные сеанса и файлы cookie. Гораздо лучшим способом было бы явно передавать некоторый уникальный токен, полученный при авторизации, в теле каждого запроса.
А веб-страницы и веб-приложения должны адаптироваться к использованию единого API. Я уверен, что все мобильные разработчики часто видели две версии API — одну для веб-приложений, другую для мобильных приложений.
Но это дублирование функционала, которое всегда дороже и на этапе разработки, и на этапе отладки.
Всегда лучше с самого начала выделить веб-сервисы в отдельный слой системы, а не встраивать их в другие части, близкие к веб-технологиям.
Возврат HTML
Это уже возвращает нас к проектированию самих веб-серверов, которые изначально были предназначены только для браузера.Ошибки 403, 404, а иногда и более сложные очень часто представлены в виде HTML-страницы, отобразить которую в мобильном приложении зачастую просто нет средств.
Точнее, средства есть, но, увидев «404 страница не найдена» в здоровенном черном цвете Arial Black на белом фоне внутри веб-представления, мобильный пользователь испугается и закроет приложение.
Помните, что сервер должен возвращать XML (или JSON) для любого вызова веб-служб и только в том формате, который был изначально согласован.
Мобильный разработчик не может сделать ничего полезного с HTML, поступающим с сервера.
Используйте WSDL
С технологиями Microsoft пока все в порядке — большинство их современных технологий поддерживают WSDL «из коробки».Чего нельзя сказать о PHP и Java — особенно PHP-разработчики любят вручную создавать обычные страницы, которые по сути являются веб-сервисами.
Но для интеграции с WSDL-совместимым веб-сервисом мобильному разработчику достаточно использовать этот инструмент только для генерации кода, а скомпилированные вручную ответы веб-сервиса также необходимо анализировать вручную.
Правда, здесь тоже есть свои тонкости — стандартные реализации WSDL от MS и Sun (Oracle) по-прежнему имеют несовместимости, но исправить эти несовместимости файлом все равно быстрее, чем писать все вручную.
Заключение
Я коснулся лишь самых серьезных ошибок дизайна, с которыми мобильным разработчикам приходится сталкиваться каждый день.Если статья будет востребована, я обязательно напишу еще о десятке клиент-серверных тонкостей, которые мне бы очень хотелось видеть в API веб-сервисов, с которыми вы работаете каждый день.
Теги: #веб-сервисы #клиент-серверная архитектура #клиент-серверные приложения #tags_no_reads #Разработка для iOS #Разработка мобильных приложений #Разработка для Android
-
Timeular Zei - Трекер Физического Времени
19 Oct, 24 -
Типы И Определения Веб-Хостинга
19 Oct, 24 -
Космические Призраки
19 Oct, 24 -
Аутентификация На Основе Цифровой Подписи
19 Oct, 24
