Пришло время завершить серию про Flutter и Rest Api. Другие статьи по теме тут
Но возникает вопрос. Как отправить запрос и работать с ответом - понятно, но как отправить JSON в теле запроса POST ?
От слов к делу
Все что нам нужно сделать это десериализовать объект в JSON.
!Важно материал создан, чтобы показать сам процесс десериализации, а не процесс отправки POST запроса, поэтому эта часть будет затронута косвенно. Но в рамках статьи мы десериализуем все часто используемые объекты.
Создаем класс ForecastContract. Десериализовывать будем строку, объект, массив объектов и массив чисел. Далее построчно
строка 66 - строка противоположная метода fromJson, там на входе был Map<String, dynamic>, а здесь наша задача получить такой массив на выходе
строка 75 - объявляем свой класс, который также десериализуем и ему также добавляем метод toJson
В нашем dataprovider классе добавим на POST метод и пройдемся построчно
отличия от метода GET минимальны
39 - десериализация
41 - метод get меняем на post
45 - отправляем тело запроса
С помощью теста посмотрим, как на практике десериализуется наш класс
На точке останова в методе postWeather видим наш десериализованный объект
Если убрать слэши и отформатируем строку в JSON получим
!Важно Слэши мы убираем потому, что это просто сигнализатор о том, что следом идет спецсимвол, в JSON без кавычек никак, а в dart кавычки это начала и конец строки, без слэша на JSON оборвался на первой же кавычке
Несколько последних штрихов
Если посмотреть на наш dataprovider, то можно увидеть неприятное дублирование кода и гипотетическое еще большее дублирование кода в дальнейшем. Чем больше мы будем создавать запросов к Api тем больше будет копироваться код с созданием клиента и обработкой ответа.
Первое что мы сделаем это уберем строку
Client client = Client();
Создаем alias для библиотеки http и, так как в этой библиотеке экспортируется только один класс компилятор сам разберется, что мы от него хотим (в сухом остатке компилятор сам создаст Client там, где это необходимо)
Далее мы вынесем обработку ответа в отдельный метод, потому что, независимо от типа запроса ответ всегда будет обрабатываться одинаково.
!Заметка стоит отметить, что обрабатывать нужно основные типы коды ошибок 200, 401, 402, 403, 500, 502, 503 ну и хипстеский 201 - успешный ответ без тела ответа.
401 - неверная авторизация
402 - неверный запрос
403 - недостаточно прав
500 - внутрення ошибка (бек опять не работает)
502 - сервер работает не так
503 - сервер вообще не работает
последние 3 от разработчика мобильного приложения не зависят вообще, но отвечать перед пользователям все равно вам, поэтому стоит на эти ошибки добавить окошко в стиле "ВСЕ СЛОМАЛОСЬ! Мы вернемся позже". Позже и сильнее.
Метод выглядит так
строка 38 - обработка ответа по новому
Вместо подведения итогов
Код можно ревьюить почти до бесконечности, основная задача ревью не допускать разрастания проекта до миллионов миллиардов строк, но при этом код должен быть читаем программистами любого уровня. Не стоит использовать библиотеки, просто ради того, чтобы использовать библиотеки. Например в текущем примере, мы можем всю логику обработки и отправки запросов вынести в отдельный абстрактный класс и создать weather_data_provider наследованный от нашего абстрактного класса, но мы не собираемся менять источник с REST http на базу данных, поэтому такой уровень абстракции не нужен. А вторых у нас всего два запроса. Также мы можем использовать библиотеку например getX, для отправки запросов и не писать всю эту обработку, но и все баги этой библиотеки мы заберем к себе проект, хотя как вы видите обработать серверны http запрос не так уж и трудно.
В следующий раз я напишу статью о том как создать классы для десериализации на основе swagger документации сервера.
Подписывайтесь, чтобы не пропустить!
И спасибо.