- ASP.NET Core: Создание серверных служб для мобильных приложений
- Второй цикл статей по ASP.NET Core
- Образец мобильного приложения
- Функции
- Создание проекта ASP.NET Core
- Создание контроллера
- Чтение элементов
- Создание элементов
- Обновление элементов
- Удаление элементов
- Создание внутренних служб для собственных мобильных приложений в ASP.NET Core
- Пример собственного мобильного приложения
- Компоненты
- Создание проекта ASP.NET Core
- Создание контроллера
- Чтение элементов
- Создание элементов
- Обновление элементов
- Удаление элементов
- Предотвращение избыточной публикации
ASP.NET Core: Создание серверных служб для мобильных приложений
Представляем вторую часть из серии статей, посвящённых разработке на ASP.NET Core. В этом обучающем материале вы узнаете, как создавать серверные службы с помощью ASP.NET Core MVC для поддержки мобильных приложений.
Второй цикл статей по ASP.NET Core
Первый цикл статей можно найти здесь.
Образец мобильного приложения
Мобильные приложения могут без труда обмениваться данными с серверными службами ASP.NET Core. Здесь можно скачать образец кода серверных служб.
В данном материале в качестве клиента используется приложение Xamarin Forms ToDoRest. Оно включает отдельные клиенты для устройств под Android, iOS и Windows. По ссылке выше вы найдёте руководство, которое поможет создать приложение (и установить необходимые бесплатные инструменты Xamarin), а также сможете скачать образец решения Xamarin. В него входит проект двух служб ASP.NET веб-API, на замену которым приходит приложение ASP.NET Core из этой статьи (со стороны клиента изменения не понадобятся).
Функции
Приложение ToDoRest поддерживает составление списков, добавление, удаление и обновление элементов To-Do. Каждый элемент наделён своим идентификатором, названием, примечаниями и свойством, которое указывает, выполнен ли элемент.
В основном представлении элементов, как показано выше, имеется название каждого элемента, а наличие флажка указывает, был ли он выполнен.
Коснитесь значка +, чтобы открыть диалоговое окно для добавления элементов:
Коснитесь элемента в главном списке, чтобы открыть диалоговое окно для редактирования названия, примечания и статуса выполнения, либо чтобы удалить элемент:
Этот образец по умолчанию использует сервисные службы, размещённые по адресу developer.xamarin.com, и позволяет выполнять только чтение. Чтобы самостоятельно протестировать его с приложением ASP.NET Core, которое будет создано в следующем разделе и будет работать на вашем компьютере, нужно обновить константу RestUrl . Перейдите к проекту ToDoREST и откройте файл Constants.cs. Замените RestUrl на IP-адрес вашего компьютера (это не должен быть localhost или 127.0.0.1, поскольку адрес используется из эмулятора устройства, а не из вашего ПК). Также добавьте номер порта (5000). Чтобы службы работали на устройстве, не забудьте выключить брандмауэр, блокирующий доступ к этому порту.
Создание проекта ASP.NET Core
Создайте новое веб-приложение ASP.NET Core в Visual Studio. Выберите шаблон веб-API и отключите аутентификацию. Присвойте проекту имя ToDoApi.
Приложение должно отвечать на все запросы к порту 5000. Добавьте в Program.cs .UseUrls(«http://*:5000») , чтобы получить следующий результат:
Примечание: обязательно запустите приложение напрямую, а не через IIS Express, который по умолчанию игнорирует не локальные запросы. Выполните dotnet run из командной строки либо выберите название приложения из раскрывающегося меню Debug Target на панели инструментов Visual Studio.
Добавьте класс модели для представления элементов To-Do. Отметьте обязательные поля с помощью атрибута [Required] :
Методам API необходим способ обработки данных. Используйте тот же интерфейс IToDoRepository , что и в образце Xamarin:
В этом примере при реализации используется частная коллекция элементов:
Настройте реализацию в Startup.cs:
Теперь можно перейти к созданию ToDoItemsController.
Создание контроллера
Добавьте к проекту новый контроллер ToDoItemsController. Он должен унаследовать свойства от Microsoft.AspNetCore.Mvc.Controller. Добавьте атрибут Route , чтобы указать, что контроллер обработает запросы, которые выполнены к путям и начинаются с api/todoitems . Токен [controller] в маршруте заменяется названием контроллера (без суффикса Controller); это особенно полезно для глобальных маршрутов. Подробнее о маршрутизации.
Для работы контроллера необходим параметр IToDoRepository; запросите экземпляр этого типа через конструктор контроллера. В среде выполнения этот экземпляр будет предоставлен благодаря поддержке платформы для внедрения зависимости.
Этот API поддерживает четыре команды HTTP для операций создания, чтения, обновления и удаления (CRUD) в источнике данных. Самая простая операция — Read (чтение), она соответствует запросу HTTP Get.
Чтение элементов
Чтобы запросить список элементов, выполните запрос GET к методу List . Атрибут [HttpGet] в методе List указывает, что это действие должно обрабатывать только запросы GET. Маршрут для этого действия — это маршрут, указанный на контроллере. Вам не обязательно использовать название действия в качестве части маршрута. Нужно лишь убедиться, что каждое действие обладает уникальным и однозначным маршрутом. Маршрутизацию атрибутов для создания конкретных маршрутов можно применять на уровне как контроллера, так и метода.
Метод List выдает код ответа 200 OK и список всех элементов ToDo, сериализованных как JSON.
Вы можете протестировать новый метод API с помощью ряда инструментов, например Postman, как показано ниже:
Создание элементов
По соглашению, создание новых элементов данных сопоставляется с командой HTTP POST. К методу Create применен атрибут [HttpPost]; кроме того, метод принимает параметр ID и экземпляр ToDoItem . Такие командные атрибуты, как [HttpPost] , могут принять строку маршрута (в этом примере
Внутри метода проверяется, правильно ли составлен элемент и существовал ли он ранее в хранилище данных; если ошибок нет, он добавляется с помощью репозитория. ModelState.IsValid выполняет проверку модели; это следует сделать в каждом методе API, который принимает вводимые пользователем данные.
В образце используется перечисление кодов ошибок, передаваемых в мобильный клиент.
Чтобы проверить добавление новых элементов, используйте Postman: выберите команду POST, которая предоставляет новый объект в формате JSON в теле запроса. Также добавьте заголовок запроса, который указывает Content-Type для application/json .
В ответе метод выдает только что созданный элемент.
Обновление элементов
Изменять записи можно с помощью запросов HTTP PUT. Кроме того, метод Edit практически идентичен Create . Помните, что если запись не будет найдена, действие Edit выдаст ответ NotFound (404).
Чтобы протестировать Postman, измените команду на PUT и добавьте ID обновляемой записи в URL. Укажите данные обновляемого объекта в теле запроса.
При успешном выполнении метод выдает ответ NoContent (204), обеспечивая тем самым согласованность с существующим API.
Удаление элементов
Для удаления записей нужно сделать запросы DELETE к сервису и передать ID удаляемого элемента. После этих обновлений запросы для несуществующих элементов получат ответы NotFound , а успешный запрос — ответ NoContent (204).
Помните, что при тестировании функции удаления в тело запроса добавлять ничего не нужно.
Источник
Создание внутренних служб для собственных мобильных приложений в ASP.NET Core
Мобильные приложения могут взаимодействовать с внутренними службами ASP.NET Core. Инструкции по подключению локальных веб-служб из симуляторов iOS и эмуляторов Android см. в статье о подключении к локальным веб-службам из симуляторов iOS и эмуляторов Android.
Пример собственного мобильного приложения
в этом руководстве показано, как создавать серверные службы с помощью ASP.NET Core для поддержки собственных мобильных приложений. Он использует приложение Xamarin. Forms тодорест в качестве собственного клиента, включая отдельные клиенты машинного кода для Android, iOS и Windows. Вы можете следовать приложенному руководству, чтобы создать собственное приложение (и установить необходимые бесплатные средства Xamarin), а также скачать пример решения Xamarin. пример Xamarin включает в себя проект служб веб-API ASP.NET Core, который заменяет приложение ASP.NET Core (без изменений, требуемых клиентом).
Компоненты
Приложение тодорест поддерживает перепись, добавление, удаление и обновление элементов To-Do. Каждый элемент имеет идентификатор, имя, заметки и свойство, указывающее, выполнен ли он.
Основное представление элементов, как показано выше, выводит список с именем каждого элемента, указывая, выполнен ли он, с помощью флажка.
Если выбрать значок + , открывается диалоговое окно добавления элемента:
При выборе элемента на экране основного списка открывается диалоговое окно редактирования, где можно изменить параметры имени, заметок и готовности элемента, а также удалить его:
чтобы протестировать себя на ASP.NET Core приложении, созданном в следующем разделе, работающем на компьютере, обновите RestUrl константу приложения.
Эмуляторы Android не работают на локальном компьютере и используют петлевой IP-адрес (10.0.2.2) для взаимодействия с локальным компьютером. Используйте Xamarin. Essentials DeviceInfo , чтобы определить, какая операционная система работает, чтобы использовать правильный URL-адрес.
Перейдите к TodoREST проекту и откройте Constants.cs файл. Файл констант. CS содержит следующую конфигурацию.
При необходимости можно развернуть веб-службу в облачной службе, такой как Azure, и обновить RestUrl .
Создание проекта ASP.NET Core
Создайте веб-приложение ASP.NET Core в Visual Studio. Выберите шаблон веб-API. Назовите проект TodoAPI.
Приложение должно отвечать на все запросы к порту 5000, включая HTTP-трафик с открытым текстом для мобильного клиента. Обновите Startup. CS так, чтобы UseHttpsRedirection оно не запускалось в разработке:
Запустите приложение напрямую, а не за IIS Express. по умолчанию IIS Express игнорирует нелокальные запросы. запустите dotnet run из командной строки или выберите профиль имени приложения в раскрывающемся списке цель отладки на панели инструментов Visual Studio.
Добавьте класс модели для представления элементов задач. Пометьте обязательные поля с помощью атрибута [Required] :
Методам API нужен определенный способ для работы с данными. Используйте тот же интерфейс ITodoRepository , который использует исходный пример Xamarin:
В этом примере реализация использует просто частную коллекцию элементов:
Настройте реализацию в файле Startup.cs:
Создание контроллера
Добавьте новый контроллер в проект TodoItemsController. Он должен наследовать от ControllerBase . Добавьте атрибут Route , чтобы указать, что контроллер будет обрабатывать запросы, выполняемые по путям, начинающимся с api/todoitems . Токен [controller] в маршруте заменяется на имя контроллера (суффикс Controller опускается) и особенно удобен для глобальных маршрутов. Дополнительные сведения о маршрутизации.
Для работы контроллеру нужен ITodoRepository ; запросите экземпляр этого типа через конструктор контроллера. Во время выполнения этот экземпляр будет предоставляться с помощью поддержки внедрения зависимостей на платформе.
Этот API поддерживает четыре различных HTTP-команды для выполнения операций CRUD (создание, чтение, обновление, удаление) с источником данных. Самой простой из них является операция чтения, которая соответствует HTTP-запросу GET.
Чтение элементов
Запрос списка элементов, выполняется с помощью отправки запроса GET в метод List . Атрибут [HttpGet] в методе List указывает, что это действие должно обрабатывать только запросы GET. Маршрут для этого действия соответствует маршруту, указанному на контроллере. Использовать имя действия в составе маршрута необязательно. Нужно лишь убедиться, что каждое действие имеет уникальный и однозначный маршрут. Атрибуты маршрутизации можно применять на уровне как контроллера, так и метода для создания определенных маршрутов.
List Метод возвращает код ответа ок 200 и все элементы TODO, сериализованные как JSON.
Вы можете проверить новый метод API с помощью различных средств, таких как Postman, как показано ниже:
Создание элементов
По соглашению создание элементов данных сопоставляется с HTTP-командой POST. Метод Create имеет примененный к нему атрибут [HttpPost] и принимает экземпляр TodoItem . Так как аргумент item передается в текст POST, этот параметр указывает атрибут [FromBody] .
Внутри метода элемент проверяется на допустимость и предшествующее существование в хранилище данных, а при отсутствии проблем он добавляется с помощью репозитория. Проверка ModelState.IsValid приводит к проверке модели и должна выполняться в каждом методе API, принимающем вводимые пользователем данные.
В примере используется enum код, содержащий коды ошибок, которые передаются мобильному клиенту:
Проверьте добавление новых элементов с помощью Postman, выбрав команду POST, предоставляющую новый объект в формате JSON в тексте запроса. Вам также нужно добавить заголовок запроса, указав Content-Type типа application/json .
Метод возвращает вновь созданный элемент в отклике.
Обновление элементов
Изменение записей осуществляется с помощью HTTP-запросов PUT. За исключением этого изменения, метод Edit практически идентичен Create . Обратите внимание, что если запись не найдена, то действие Edit возвратит отклик NotFound (404).
Чтобы выполнить проверку с помощью Postman, измените команду на PUT. Укажите обновленные данные объекта в тексте запроса.
Этот метод возвращает отклик NoContent (204) при успешном выполнении, чтобы обеспечить согласованность с ранее существовавшими API.
Удаление элементов
Удаление записей сопровождается отправкой запросов DELETE в службу и передачей идентификатора удаляемого элемента. Как и в случае с обновлениями, запросы несуществующих элементов будут получать отклики NotFound . В противном случае успешный запрос получит отклик NoContent (204).
Обратите внимание, что при тестировании функции удаления в тексте запроса не требуется никаких элементов.
Предотвращение избыточной публикации
В настоящее время пример приложения предоставляет весь объект TodoItem . Рабочие приложения обычно ограничивают вводимые данные и возвращают их с помощью подмножества модели. Это связано с несколькими причинами, и безопасность является основной. Подмножество модели обычно называется объектом передачи данных (DTO), моделью ввода или моделью представления. В этой статье используется DTO.
DTO можно использовать для следующего:
- Предотвращение избыточной публикации.
- Скрытие свойств, которые не предназначены для просмотра клиентами.
- Пропуск некоторых свойств, чтобы уменьшить размер полезной нагрузки.
- Сведение графов объектов, содержащих вложенные объекты. Сведенные графы объектов могут быть удобнее для клиентов.
Чтобы продемонстрировать подход DTO, см. раздел предотвращение избыточной отправки .
Источник