Разработка REST сервиса для мобильного приложения, предназначенного для составления собственных путешествий и планирования бюджета

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Разработка REST сервиса для мобильного приложения, предназначенного для составления собственных путешествий и планирования бюджета



Введение

Программа учебной практики по профилю специальности является частью основной профессиональной образовательной программы в соответствии с ФГОС СПО по специальности 09.02.03 «Программирование в компьютерных системах» в части освоения основных видов профессиональной деятельности.

На преддипломной практике необходимо собрать материал по своему дипломному проекту, и начать разработку программного продукта.



1. Сбор материала на предприятии по теоретической части по заданию на ВКР

1.1 Проектирование API приложения

API не существуют в изоляции. Современные API являются способом совместного использования возможностей служб. В случае правильной реализации API, используемые внутри организации, могут обеспечить совместимость и эффективное повторное применение. Открытые API, используемые вне организации, могут увеличить охват вашего бизнеса, позволяя разработчикам расширить предоставляемые вами услуги. Легкость использования для потребителей жизненно важна для внедрения API.

Потребителями являются разработчики. Это могут быть разработчики вашей собственной организации или сторонние разработчики. Эти разработчики ожидают API, которые можно быстро изучить, легко применить и которые направлены на их цели. Использование API должно быть более быстрым и целесообразным, чем кодирование альтернативного решения. Успешный API стимулирует разработчиков его использовать самостоятельно или совместно с другими разработчиками.

Проектировщик любого API должен рассмотреть следующие функциональные требования:

Какие функции необходимо предоставить и как.

Моделирование API, который удовлетворяет потребности пользователя и соответствует принципам поддержки REST.

Правильно спроектированный API прост для понимания и реализации.

Думая об API как о коммерческом продукте, можно выделить его из традиционных интерфейсов прикладных программ. Традиционный интерфейс прикладных программ представляет часть программного обеспечения, которое вы создаете и разворачиваете. Современный API представляет собой пакет функций, которые привлекательны для пользователя и независимы от определенного базового программного обеспечения. API проектируется с точки зрения независимого пользователя. Перед его разработкой необходимо понимать:

Кто такой пользователь? Вы можете иметь одного четкого целевого пользователя для API или множество пользователей. Если у вас множество пользователей, вы должны понимать каждого из них.

Чего они хотят? Вместо фокусировки на том, что API может делать, то есть на его функциях и возможностях, подумайте о способах, которыми он может применяться.

Как можно сделать эти способы использования максимально легкими? Подумайте о:

Стабильности

Как можно минимизировать для потребителя нарушения при изменении API?

Гибкости

Хотя невозможно полностью охватить все возможности, как можно обеспечить гибкость для потребителя? Простым примером является разрешение вводить символы в любом регистре.

Совместимости

Какие стандарты можно установить для API, чтобы потребители знали, чего ожидать?

Документации

Какую документацию можно предоставить, и как это сделать максимально просто?

1.2 Проектирование URI

С точки зрения ресурсов адресации клиентских приложений URI определяют, насколько интуитивно понятными является веб-служба REST, и будет ли служба применяться теми способами, которых ожидают разработчики. URI веб-службы REST должны быть интуитивно понятными в том, о чем легко догадаться. Думайте об URI как о разновидности самодокументированного интерфейса, который не требует или требует небольших объяснений и справочной информации для понимания разработчиком того, на что он направлен и с какими ресурсами связан. С этой целью структура URI должна быть простой, предсказуемой и легко понимаемой.

Одним из способов достижения этого уровня легкости использования является определение URI наподобие структуры каталогов. Этот тип URI является иерархическим и имеет один корневой путь, ветви которого являются подчиненными путями, предоставляющими главные области службы. В соответствии с этим определением URI -- это не просто разделенная косыми чертами строка, но дерево с главными и подчиненными ветвями, соединенными в узлах. Например, в службе организации нитей обсуждения, которая собирает различные разделы, можно определить такой структурированный набор URI:

http://www.myservice.org/discussion/topics/{topic}

Под корневым элементом /discussion расположен узел /topics. Ниже расположен ряд имен разделов, таких как technology и так далее, каждый из которых указывает на нить обсуждения. В этой структуре легко указать нити обсуждения, просто введя что-то после /topics/.

В некоторых случаях для самого пути к ресурсу особенно подходит структура, подобная структуре каталогов. Ресурсы, например, можно организовать по дате, что очень хорошо соответствует иерархическому синтаксису. Этот пример интуитивно понятен, так как основан на правилах: http://www.myservice.org/discussion/2008/12/10/{topic}. Первый фрагмент пути является четырьмя цифрами года, второй -- двумя цифрами даты, а третий -- двумя цифрами месяца. Это та простота, которой мы добиваемся. Люди и машины могут легко сгенерировать структурированные URI, подобные этому, так как они основаны на правилах. Заполнение частей пути в слоты синтаксиса делает их пригодными, так как существует точный шаблон, по которому они составляются: http://www.myservice.org/discussion/{year}/{day}/{month}/{topic}

Ниже приведены некоторые дополнительные рекомендации, которые следует учесть, обдумывая структуру URI для веб-службы с поддержкой REST:

Скройте технологические расширения файлов сценариев на стороне сервера (.jsp, .php, .asp), если они есть, для возможности преобразования в другой язык сценариев без изменения URI.

Набирайте все символы в нижнем регистре.

Подставляйте вместо пробелов дефисы или знаки подчеркивания.

Максимально избегайте использования строк запросов.

Если URI запроса предназначен для частичного пути, вместо использования кода 404 NotFound всегда предоставляйте в качестве ответа страницу по умолчанию или ресурс.

URI также должны быть статическими, чтобы при изменении ресурсов или реализации службы не менялись ссылки. Это позволяет пользоваться закладками. Также важно, чтобы взаимосвязи между ресурсами, закодированными в URI, оставались независимыми от способа представления этих взаимосвязей там, где они хранятся.

1.3 Применение методов HTTP

программный веб интерфейс сервер

Одним из важнейших свойств веб-службы с поддержкой REST является явное использование методов HTTP в соответствии с протоколом, определенным в RFC 2616. Например, операция HTTP GET определена как метод генерации данных, предназначенный для применения клиентским приложением для извлечения ресурса, для выборки данных с веб-сервера или для выполнения запроса с ожиданием ответа веб-сервера в виде набора соответствующих ресурсов.

REST рекомендует разработчикам использовать методы HTTP явно и тем способом, который совместим с определением протокола. Этот основной принцип проекта REST устанавливает взаимно однозначное преобразование между операциями создания, чтения, изменения и удаления (CRUD) и методами HTTP. А соответствии с этим преобразованием:

Для создания ресурса на сервере используйте POST.

Для извлечения ресурса используйте GET.

Для изменения состояния ресурса или его обновления используйте PUT.

Для удаления ресурса используйте DELETE.

Многим веб-API присущ досадный недостаток проекта, который состоит в использовании методов HTTP для непреднамеренных целей. Например, URI запроса HTTP GET обычно определяет один ресурс. Или строка запроса в URI содержит набор параметров, который определяет критерии поиска, используемые сервером для нахождения набора соответствующих ресурсов. По крайней мере так HTTP/1.1 RFC описывает операцию GET. Но существует много непривлекательных веб-API, используйте используют операцию HTTP GET для активации транзакций на сервере, например, для добавления записей в базу данных. В этих случаях URI запроса GET используется неправильно или, по крайней мере, не соответствует принципам разработки RESTful. Если веб-API использует GET для вызова удаленных процедур, он имеет такой вид: GET /adduser?name=Robert HTTP/1.1

Это не очень привлекательный проект, потому что этот веб-метод поддерживает операцию изменения состояния посредством HTTP GET. Другими словами, этот запрос HTTP GET имеет побочные эффекты. При успешной обработке результатом запроса является добавление нового пользователя (в этом примере Robert) в хранилище данных. Проблема здесь главным образом семантическая. Веб-серверы предназначены для ответа на запросы HTTP GET в виде извлечения ресурсов, которые соответствуют пути (или критериям запроса) в URI запроса, и их возврата или представления в ответе, но не для добавления записи в базу данных. С точки зрения правильного использования метода протокола, и с точки зрения совместимых с HTTP/1.1 веб-серверов, такое применение GET является неверным.

Кроме семантики, другая проблема GET состоит в том, что при активации удаления, изменения или добавления записи базы данных, а также при изменении состояния сервера таким способом, это активирует инструменты веб-индексации (индексаторы) и службы поиска для внесения непреднамеренных изменений на сервере путем простой индексации ссылки. Простым способом решения этой распространенной проблемы является перемещение имен и значений параметров из URI запроса в теги XML. Результирующие теги (представление XML сущности для создания) могут быть отправлены в теле HTTP POST, чей URI запроса является предназначенным для этого родительским элементом сущности:

До:

GET /adduser?name=Robert HTTP/1.1

После:

POST /users HTTP/1.1

Host: myserver

Content-Type: application/xml

<user><name>Robert</name>

</user>

Этот метод служит примером запроса с поддержкой REST, который правильно использует HTTP POST и включает полезную нагрузку в тело запроса. С получающей стороны запрос может быть обработан путем добавления содержащегося в теле ресурса как подчиненного для ресурса, который определен в URI запроса. В этом случае новый ресурс должен быть добавлен как дочерний элемент для /users. Это отношение включения между новой сущностью и ее родителем, как указано в запросе POST, аналогично способу подчинения файла его родительскому каталогу. Клиент настраивает отношение между сущностью и ее родителем и определяет новый URI сущности в запросе POST.

Клиентское приложение может затем получить представление ресурса с помощью нового URI, учитывая что по крайней мере логически ресурс расположен в /users:

HTTP GET request GET /users/Robert HTTP/1.1

Host: myserver

Accept: application/xml

Такое использование GET является правильным, так как операция GET предназначена только для получения данных. GET -- это операция, которая не должна приводить к побочным эффектам, что также называется идемпотентностью. Подобный рефакторинг веб-метода также необходимо применить в тех случаях, где операция обновления поддерживается посредством HTTP GET:

GET /updateuser?name=Robert&newname=Bob HTTP/1.1

Это изменяет атрибут имени ресурса. Строки запроса не плохи (они хороши для реализации спецификаций фильтров, например), но шаблон строка-запроса-как-сигнатура-метода, который используется в этом простом примере, может быть неудачным при использовании для более сложных операций. Так как целью является явное использование методов HTTP, более соответствующий философии REST подход - это отправка запроса HTTP PUT для обновления ресурса вместо HTTP GET по вышеуказанным причинам.

PUT /users/Robert HTTP/1.1

Host: myserver

Content-Type: application/xml

<?xml version="1.0"?>

<user><name>Bob</name>

</user>

Использование операции PUT для замены исходного ресурса предоставляет более ясный интерфейс, совместимый с принципами REST и с определениями методов HTTP. В этом примере запрос PUT является явным в том смысле, что он указывает на ресурс, который должен быть обновлен, определяя его в URI запроса, и в том смысле, что он передает новое представление ресурса с клиента на сервер в теле запроса PUT вместо передачи атрибутов ресурса в виде свободного набора имен и значений параметров в URI запроса. Это также приводит к переименованию ресурса с Robert на Bob, и это изменяет его URI на /users/Bob. В веб-службе REST последующие запросы для ресурса, использующие прежний URI, сгенерируют стандартную ошибку 404 NotFound.

Другим моментом является обработка больших наборов результатов. Стандартный подход состоит в использовании явного разбиения на страницы: операция GET возвращает ограниченное количество объектов, когда она вызвана для набора (независимо от применения фильтра), и ссылку на следующую страницу или пакет, который может быть запрошен. Размер страницы может быть включен в GET (например, как параметр строки запроса), и если существует опасность слишком большого возврата, он должен быть установлен по умолчанию на тот случай, когда инициатор забыл его установить.

Как общий принцип проектирования, он помогает следовать рекомендациям REST по явному использованию методов HTTP посредством использования в URI существительных вместо глаголов. В веб-службе с поддержкой REST глаголы POST, GET, PUT и DELETE уже определены протоколом. И в идеале, для поддержки обобщенности интерфейса и для предоставления возможности клиентам явно указывать вызываемые ими операции веб-служба не должна определять дополнительные глаголы или удаленные процедуры, такие как /adduser или /updateuser. Этот общий принцип проектирования также применяется к телу запроса HTTP, который предназначен для передачи состояния ресурса, а не передачи имени вызываемого удаленного метода или удаленной процедуры.



2. Выполнение работ на предприятии по практической части задания на ВКР

Постановка задачи:

Разработать REST сервис для мобильного приложения “Travel Assistent”, предназначенного для составления собственных путешествий и планирования бюджета.

Разработка RESTAPI сервиса включает в себя:

Проектирование API приложения

Написание документации

Написание программного кода

Подключение БД

Написание HTTP - запросов

Тестирование запросов

Деплой сервиса на сервер

Тестирование

Программный код написан на объектно - ориентированном языке Java, с использованием фреймворка Spring, который является ключевой технологией в разработке данного сервиса. Структура проекта указана на рисунке 1.



Рисунок 1. Структура проекта

Так же, в проекте я использовала фреймворк ApacheMaven, предназначенный для автоматизации сборки проекта на основе описания их структуры на языке POM (листинг 1).

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

<modelVersion>4.0.0</modelVersion>

<groupId>org.example</groupId>

<artifactId>travelapp</artifactId>

<version>1.0-SNAPSHOT</version>

<parent>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-parent</artifactId>

<version>2.3.9.RELEASE</version>

</parent>

<properties>

<maven.compiler.source>15</maven.compiler.source>

<maven.compiler.target>15</maven.compiler.target>

</properties>

<dependencies>

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-web</artifactId>

</dependency>

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

<dependency>

<groupId>com.h2database</groupId>

<artifactId>h2</artifactId>

<!-- <scope>runtime</scope>-->

</dependency>

<dependency>

<groupId>org.projectlombok</groupId>

<artifactId>lombok</artifactId>

<optional>true</optional>

</dependency>

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-data-jpa</artifactId>

</dependency>

<dependency>

<groupId>org.hibernate</groupId>

<artifactId>hibernate-entitymanager</artifactId>

<version>5.4.30.Final</version>

</dependency>

<dependency>

<groupId>org.hibernate</groupId>

<artifactId>hibernate-core</artifactId>

<version>5.4.30.Final</version>

</dependency>

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot</artifactId>

<version>2.3.9.RELEASE</version>

</dependency>

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-autoconfigure</artifactId>

<version>2.3.9.RELEASE</version>

</dependency>

</dependencies>

Листинг 1

Для тестирования HTTP запросов (Листинг 2) применялся Postman (сервис для проверки запросов с клиента на сервер и получения ответа от сервера), (Рис. 2).

@RestController

public class RoutesController {

private final RoutesRepository repository;

RoutesController(RoutesRepository repository){

this.repository = repository;

}

@GetMapping("/routes")

public ResponseEntity all() {

List<Routes> routes = repository.findAll();

return new ResponseEntity(routes, HttpStatus.OK);

}

@GetMapping("/routes/{id}")

public ResponseEntity one(@PathVariable Long id) {

Routes routes = repository.findById(id).orElseThrow(() -> new RoutesNotFoundException(id));

return new ResponseEntity(routes, HttpStatus.OK);

}

}

Листинг 2. Пример GET - запросов

Рисунок 2. Тестирование HTTP - запросов в Postman

Результатом работы моего сервиса является получение ответов от сервера в формате json.

Так же, для реализации сервиса необходимо разработать базу данных.

Цель базы данных:

Хранение и контроль информации о пользователях, маршрутах и его составляющих.

Реализация:

Разработка базы данных в данном проекте осуществлялась с помощью H2 database - открытой кроссплатформенной СУБД, написанной на языке Java.

На рисунке 3 изображена часть базы данных, хранящая в себе информацию о маршрутах пользователей.

Рисунок 3. Фрагмент базы данных

H2 - это полностью интегрированная СУБД, поэтому создание таблиц осуществлялось непосредственно в коде программы (Рис. 4).



Рисунок 4. Создание таблицы "Маршруты

Далее таблицы были заполнены тестовыми данными с помощью SQL- запросов.

Ниже приведен пример заполнение таблицы “Адреса” (Листинг 3).

INSERT INTO ADDRESS_HOTELS(ID, BUILDING, CITY, COUNTRY, STREET)

VALUES ('1', '10', 'Санкт-Петербург', 'Россия', 'Леснаяул.');

INSERT INTO ADDRESS_HOTELS(ID, BUILDING, CITY, COUNTRY, STREET)

VALUES ('2', '4', 'Москва', 'Россия', 'Тимирязевскаяул.');

INSERT INTO ADDRESS_HOTELS(ID, BUILDING, CITY, COUNTRY, STREET)

VALUES ('3', '14', 'Берлин', 'Германия', 'EislebenerStrassee');

INSERT INTO ADDRESS_HOTELS(ID, BUILDING, CITY, COUNTRY, STREET)

VALUES ('4', '32', 'Лондон', 'Великобритани', 'Grassmarket Edinburgh');

INSERT INTO ADDRESS_HOTELS(ID, BUILDING, CITY, COUNTRY, STREET)

VALUES ('5', '3', 'Мадрид', 'Испания', 'C/EnricMorera');

INSERT INTO ADDRESS_HOTELS(ID, BUILDING, CITY, COUNTRY, STREET)

VALUES ('6', '20', 'Баку', 'Азурбайджан', 'ул. АкадемикаГасанаАлиева');

INSERT INTO ADDRESS_HOTELS(ID, BUILDING, CITY, COUNTRY, STREET)

VALUES ('7', '11', 'Пекин', 'Китай', 'Tiatong Lu');

INSERT INTO ADDRESS_HOTELS(ID, BUILDING, CITY, COUNTRY, STREET)

VALUES ('8', '19', 'Париж', 'Франция', 'Boulevard de IErope');

INSERT INTO ADDRESS_HOTELS(ID, BUILDING, CITY, COUNTRY, STREET)

VALUES ('9', '37', 'Париж', 'Франция', 'Route de Chalifert');

INSERT INTO ADDRESS_HOTELS(ID, BUILDING, CITY, COUNTRY, STREET)

VALUES ('10', '10', 'Токио', 'Япония', 'Takanawa, Minato-ku');

Листинг 3



Заключение

На преддипломной практике я собирала теоретический материал по своему дипломному проекту, так же начала делать практическую часть.

Размещено на Allbest.ru

...