├── Lab 3 ├── Лабораторна ООП.docx └── README.md ├── Lab 1 └── README.md ├── Lab 2 └── README.md ├── README.md ├── Lab 7 └── README.md ├── Lab 8 └── README.md ├── Lab 6 └── README.md ├── Lab 9 └── README.md ├── Lab 4 └── README.md └── Lab 5 └── README.md /Lab 3/Лабораторна ООП.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/shymanskyivm/Labs_For_Application_Programming/HEAD/Lab 3/Лабораторна ООП.docx -------------------------------------------------------------------------------- /Lab 1/README.md: -------------------------------------------------------------------------------- 1 | # Основи Python 2 | 3 | Зареєструватись на сайті [snakify.org](snakify.org) використовуючи аккаунт з домену lpnu.ua. 4 | 5 | Виконати індивідуальні завдання для тем 1 - 6. 6 | -------------------------------------------------------------------------------- /Lab 2/README.md: -------------------------------------------------------------------------------- 1 | # Основи Python 2 | 3 | Зареєструватись на сайті [snakify.org](snakify.org) використовуючи аккаунт з домену lpnu.ua. 4 | 5 | Виконати індивідуальні завдання для тем 7 - 11. 6 | -------------------------------------------------------------------------------- /Lab 3/README.md: -------------------------------------------------------------------------------- 1 | # Об’єктно-орієнтоване програмування в Python 2 | 3 | Розробити програму для демонстрації реалізації розроблених класів, згідно індивідуальних завдань. Окрім інструкцій вказаних в індивідуальних варіантах, створені класи повинні містити: 4 | - Конструктор за замовчуванням та з переданими параметрами; 5 | - Перевизначити метод __str__; 6 | - Використати різні модифікатори для атрибутів екземпляру класу; 7 | - Використати атрибут класу; 8 | - Реалізувати властивості (property) для доступу до атрибуту; 9 | - Статичний метод; 10 | - Реалізований декоратор методу. 11 | - Перевантажити математичні оператори (+, -, *, /) 12 | - Перевантажити логічні оператори (>, <, >=, <=, ==, !=) 13 | 14 | Детальний опис лабораторної та індивідуальних завдань у файлі 15 | *Лабораторна ООП.docx* 16 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Загальні вимоги 2 | 3 | 1. Результатом виконання лабораторних робіт (4 - 9) даного курсу має стати серверна частина проекту, який буде використовуватися на курсі Веб програмування. 4 | 2. При написанні лабораторних робіт обов’язково дотримуватися стандарту коду [PEP-8](https://www.python.org/dev/peps/pep-0008/) та здорового глузду, зокрема: 5 | * Використовувати загальноприйняті правила іменування (variable_name, function_name, ClassName, CONSTANT_NAME) 6 | * Використовувати змістовні імена англійською для змінних, функцій, класів та файлів (не `a`, `b`, `foo`, `bar`, `i_bez_transliteratsii_ukrainskykh_sliv`) 7 | * Уникати довгих рядків (80+ символів) 8 | * Стратегічне використання пробільних символів для покращення читаємості коду (пусті рядки для візуального групування, пробіли навколо операторів в т.д.) 9 | 3. Потрібно використовувати не системний інтерприратор Python, а віртуальне середовище ([virtual environments](https://docs.python.org/3/tutorial/venv.html)) 10 | 4. При роботі над проектом потрібно використовувати систему контролю версій Git на платформі GitHub, GitLab чи іншій 11 | * Робота над кожною лабораторною має починатись зі створення гілки `lab-<номер лабораторної>` (`lab-1`) в яку мають комітитись зміни до коду проекту, що відповідають даній лабораторній 12 | * По закінченню роботи над лабораторною, відповідна гілка маю бути злита з гілкою master шляхом створення merge request (він же ж pull request) у відповідній платформі (GitHub чи GitLab) 13 | -------------------------------------------------------------------------------- /Lab 7/README.md: -------------------------------------------------------------------------------- 1 | # Імплементація REST API 2 | 3 | В даній лабораторній роботі потрібно реалізувати REST API спроектоване в другій лабораторній використовуючи моделі створені у третій лабораторній. Дана лабораторна не включає авторизацію користувачів та перевірку прав доступів до тих чи інших ресурсів чи операцій. 4 | 5 | ## Рекомендації 6 | 7 | * Під час розробки зручно використовувати `flask run` в дебаг режимі, тоді сервіс автоматично буде перезавантажуватись при зміні коду 8 | * Для валідації даних можна використати пакет [marshmallow](https://marshmallow.readthedocs.io/en/stable/) 9 | * Для хешування паролів користувачів можна використати пакет [Flask-Bcrypt](https://flask-bcrypt.readthedocs.io/en/latest/) 10 | 11 | ## Хід роботи 12 | 13 | 1. Реалізувати логіку кожної з адрес з валідацією даних 14 | 3. Реалізувати коректну поведінку при різних помилках (повернення коректного контенту та HTTP статус кодів) 15 | 4. Перевірити коректність реалізації за допомогою Postman, curl чи інших засобів 16 | 17 | ## Критерії оцінювання 18 | 19 | 1. Реалізовані всі операції описані в `swagger.yaml` в другій лабораторній 20 | 2. Паролі користувачів зберігаються у захешованому виді 21 | > Показати як паролі шифруються або зробити запит на створення користувача та показати що, користувач збережений в базі даних з захешованим паролем 22 | 3. Вхідні дані валідуються по типу полів на інших параметрах залежно від варіанту 23 | > Показати валідацію вхідних даних в коді 24 | 4. При помилках повертається JSON-відповідь зі HTTP статус кодом відповідно до помилки 25 | > Показати код відповідальний за відповіді при помилках 26 | 5. Продемонструвати кілька запитів до розробленого API (один з них має демонструвати поведінгку при помилках) за допомогодю Postman, curl чи інших засобів -------------------------------------------------------------------------------- /Lab 8/README.md: -------------------------------------------------------------------------------- 1 | # Автентифікація і авторизація 2 | 3 | В даній лабораторній порібно реалідізувати автентифікацію та авторизацію користувачів для розробленого REST API. Автентифікація є перевіркою того, що запит відбувається від імені конкретного користувача. Авторизація є перевіркою того чи має конкретний користувач доступ до конкретної операції над певним ресурсом. 4 | 5 | Для автентифікації до REST API замість типової для веб-сторінок моделі автентифікації на базі HTTP-cookie як правило виконують так звану [HTTP автентифікацію](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication). Зі сторони клієнта HTTP автентифікація виконується за допомогою хедера `Authorization`. Значення даного хедера можуть мати різні [схеми автентифікації](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#Authentication_schemes), та . Ми будемо розглядати дві такі схеми, а саме: Basic та Bearer. 6 | 7 | При Basic смемі значення хедера виглядає наступним чином: `Basic `. Де `` це закодована в Base64 стрічка наступного виду: `username:password`. 8 | 9 | При Bearer схемі значення хедера виглядає наступним чином: `Bearer `. Де `` є токеном автентифікації. Оригінально дану схему створили для токенів згенерованих при OAuth 2.0 авторизації, однак Bearer схеми використовуються для передачі токерів різного формату, як наприклад JWT-токени. Іноді для передачі JWT-токенів вказують схему `JWT`, однак вона не включена в офіційний стандарт. 10 | 11 | ## Варіанти 12 | 13 | Номер варіанту визначається номером студента в журналі. 14 | 15 | Залежно від номеру визначається схема HTTP автентифікації, яку потрібно реалізувати: 16 | * непарні номери - Basic 17 | * парні номери - Bearer (з JWT-токеном) 18 | 19 | ## Рекомендації 20 | 21 | * Для спрощення реалізації Basic-автентифікації можна використати пакет [flask-HTTPAuth](https://flask-httpauth.readthedocs.io/en/latest/#basic-authentication-examples) 22 | * Для спрощення реалізації JWT-автентифікації можна використати пакет [Flask-JWT](https://pythonhosted.org/Flask-JWT/) 23 | 24 | ## Хід роботи 25 | 26 | 1. Реалізувати автентифікацію користувачів обраним механіхмом, обмежити доступ до операцій над ресурсами для запитів, що не відповідають обраному механізму автентифікації 27 | 2. Реалізувати авторизацію користувачів, перевіряти права доступу для того чи іншого користувача, повертати ресурси, що належать конкретному користувачеві 28 | 3. При необхідності передбачити наявність супер-користувача для здійснення усіх чи певних операцій 29 | 4. Перевірити коректність роботи автентифікації та авторизації здійснивши кілька запитів до системи 30 | 31 | ## Критерії оцінювання 32 | 33 | 1. Продемонстрована реалізація автентифікації та авторизації користувачів в коді системи 34 | 2. Продемонстрована автентифікація користувача та виконання певних операцій з системою через виконання запитів до системи 35 | -------------------------------------------------------------------------------- /Lab 6/README.md: -------------------------------------------------------------------------------- 1 | # ORM та міграції 2 | 3 | При роботі з базою даних часто використовують ORM-бібліотеки (Object–relational mapping). Такі бібліотеки дають більш високорівневий та безпечний інтерфейс для взаємодії з базою даних. В ORM-бібліотеках класи-моделі представляють таблиці бази даних, а екземпляри цих класів - окремі записи в таблицях. Окрім того ORM-бібліотеки дозволяють переключатись між різними СУБД без зміни коду програми. 4 | 5 | Найпопулярнімими ORM для Python є Django ORM та [SQLAlchemy ORM](https://docs.sqlalchemy.org/en/latest/orm/). Django ORM є частиною фреймворку Django, тому використовується як правило для Django-проектів, тоді як SQLAlchemy ORM є самостійної бібліотекою не прив'язаною до фреймворку. Тому SQLAlchemy часто використовують у проектах з альтернативними фреймворками та загалом Python-програмами, що працюють з базами даних. 6 | 7 | Скрипти міграцій є скриптами, які містять зміни, що були внесені до моделей в новій версії коду системи. Скрипти міграцій можуть застосовувати або скасовувати відповідні зміни таким чином даючи можливість підніматись та спускатись по історії змін до моделей бази даних. 8 | 9 | SQLAlchemy ORM не має вбудованих інструментів для створення скрпитів маграцій. Для цього, як правило, використовують бібліотеку [Alembic](https://alembic.sqlalchemy.org/en/latest/). 10 | 11 | В даній лабораторній роботі потрібно описати структуру бази даних для системи та реалізувати її замобами SQLAlchemy ORM, а також створити файли міграцій за допомогою Alembic. 12 | 13 | ## Рекомендації 14 | 15 | * Для того, щоб Alembic мав доступ до створених моделей потрібно модифікувати скрипт `env.py`, згенерований командою `alembic init` 16 | * Для того, щоб Alembic створював непусті скрипти міграцій, команді `alembic revision` потрібно передавати флаг `--autogenerate` 17 | 18 | ## Хід роботи 19 | 20 | 1. Описати структуру бази даних, зробити діаграму з таблицями та зв'язками між ними 21 | 2. Встановити одну з реляційних СУБД, які SQLAlchemy [підтримує](https://docs.sqlalchemy.org/en/13/dialects/) (PostgreSQL, MySQL чи іншу) 22 | 3. Створити у базі даних необхідні таблиці за допомогою SQL запитів чи графічного інтерфейсу до обраної СУБД 23 | 4. Створити SQLAlchemy ORM моделі для таблиць та спробувати використати їх для операцій над базою даних 24 | 5. Видалити попередньо створені вручну таблиці та створити автоматично-згенерований скрипт міграції за допомогою Alembic, застосувати створений скрипт міграції 25 | 26 | ## Критерії оцінювання 27 | 28 | 1. Описана структура бази даних для системи на наявна діаграма 29 | 2. Усі таблиці описані SQLAlchemy ORM моделями 30 | 3. Створено скрипт міграції для створення таблиць для моделей 31 | > якщо alembic ініційовано в директорій `./alembic`, то в директорії `./alembic/versions` має бути Python-файл з непустими функціями `upgrade` та `downgrade` 32 | 4. Таблиці в базі даних створені за допомогою Alembic міграцій 33 | > в базі даних серед інших таблиць має бути таблиця `alembic_version` з версією застосованої міграції -------------------------------------------------------------------------------- /Lab 9/README.md: -------------------------------------------------------------------------------- 1 | # Тестування 2 | 3 | При розробці REST API часто використовують інтеграційні тести, які також називають API-тестами. Як правило такі тести поєднуються з unit-тестами. Пропорції поєднання інтеграційних та unit-тестів можуть бути різними. 4 | 5 | В традиційній піраміді тестування Майка Кона пріоритет надається unit-тестам, оскільки такі тести швидко виконуються та дозволяють протестувати більшість якщо не всі варіанти поведінки коду, що тестується. 6 | 7 | У свою чергу API-тести дозволяють протестувати REST API схоже до того як би його використовував користувач з прив'язкою тільки до інтерфейсу сервісу, а не його внутрішньої реалізації, що спрощує початкові етапи розробки та подальший рефакторінг. Окрім того деякі елементи коду, як наприклад об'єкти для роботи з ORM, може бути проблематично заміняти мок-об'єктами без створення залежностей на деталі реалізації. Саме тому в деяких проектах пріоритет надають саме API-тестам, залишаючи unit-тести для окремих частин коду які проблематично протестувати API-тестами. Таких підхід особливо популярний в поєднанні з мікросервісною архітектурою, оскільки для невеликих сервісів порівняно легко описати всю їх поведінку через API-тести. 8 | 9 | Вміст більшості API-тестів можна поділити на наступні частини: 10 | 1. Задання внутрішнього стану сервісу (наприклад, створення записів в базі даних) 11 | 2. Відправка запиту до сервісу 12 | 3. Оцінка відповіді сервісу (наприклад, оцінка контенту відповіді, HTTP статус коду) 13 | 4. Оцінка внутрішнього стану сервісу після запиту (наприклад, перевірка того які записи знаходяться в базі даних) 14 | 15 | Міграції бази даних можна застосовувати для кожного тесту окремо, що може сповільнити їх виконання, або один раз для всіх тестів загалом, однак в такому випадку кожен тест має починати роботу з пустими таблицями моделей, щоб між тестами не створювалось неявних залежностей. Тести мають проходити незалежно від того, в якому порядку вони були виконані. 16 | 17 | В даній лабораторній роботі потрібно створити тести для перевірки правильності роботи системи. Студенти можуть надавати пріоритет API або unit-тестам за бажанням. Тести мають покривати більше 90% коду системи (перевірити за допомогою пакету [coverage](https://coverage.readthedocs.io/en/stable/)). 18 | 19 | ## Варіанти 20 | 21 | Номер варіанту визначається номером студента в журналі. 22 | 23 | Залежно від номеру визначається фреймворк для тестування, що потрібно буде використовувати: 24 | * непарні номери - [unittest](https://docs.python.org/3/library/unittest.html) 25 | * парні номери - [pytest](https://docs.pytest.org/en/stable/) 26 | 27 | ## Рекомендації 28 | 29 | * Для спрощення API тестування Flask додатків фреймворком unittest зручно використовувати пакет [Flask-Testing](https://pythonhosted.org/Flask-Testing/) 30 | * Для спрощення API тестування Flask додатків фреймворком pytest зручно використовувати пакет [pytest-flask](https://pytest-flask.readthedocs.io/en/latest/tutorial.html) 31 | * Якщо `coverage` показує занадто низький відсоток покриття, варто перевірити чи не включаються в репорт зайві файли (включатись мають тільки файли самої системи, без включення файлів сторонніх пакетів) 32 | 33 | ## Хід роботи 34 | 35 | 1. Встановити необхідні залежності 36 | 2. Створити API та/або unit тести для перевірки функціоналу 37 | 3. Переконатись, що покриття коду системи тестами вище 90% 38 | 39 | ## Критерії оцінювання 40 | 41 | 1. Створені API та/або unit тести успішно проходять при запуску 42 | 2. В тестах виконуються авторизовані запити до системи 43 | 3. В тестах використані фікстури (pytest фікестури або setUp/tearDown для unittest) 44 | 4. Покриття коду системи тестами вище 90% 45 | -------------------------------------------------------------------------------- /Lab 4/README.md: -------------------------------------------------------------------------------- 1 | # Ініціалізація проекту 2 | 3 | На різних проектах використовують різні версії інтерпритатора, інструменти для створення віртуальних Python середовищ та управління залежностями. Для нових членів команди важливо вміти підлаштуватись під ті інструменти які вже використовуються в проекті. 4 | 5 | Для командної роботи та збереження історії змін використовують системи контролю версій (наприклад, Git). Для збереження репозиторію часто використовують платформи типу GitHub, GitLab, Bitbucket та інші. 6 | 7 | В даній лабораторній роботі потрібно ініціалізувати проект інструментами згідно з варіантом, створити простий Flask-проект та запустити його використовуючи WSGI сервер. Також в репозиторії має бути файл `README.md` з інструкцією по розгортанню проекту після клонування (створення віртуального середовища і встановлення залежностей) з використанням відповідних інструментів. Створений код має бути збережений в системі контролю версій. 8 | 9 | ## Варіанти 10 | 11 | Номер варіанту визначається номером студента в журналі. 12 | 13 | Можливі варіанти версії Python: 14 | 1. `3.8.*` 15 | 2. `3.7.*` 16 | 3. `3.6.*` 17 | 18 | Можливі варіанти інструментів для створення віртуальних середовищ та управління залежностями: 19 | 1. [venv](https://docs.python.org/3/tutorial/venv.html) (вбудований в інтерпретатор) та requirements.txt 20 | 2. [virtualenv](https://virtualenv.pypa.io/en/stable/) 21 | 3. [poetry](https://python-poetry.org/) 22 | 4. [pipenv](https://pipenv.pypa.io/en/latest/) 23 | 24 | Вимоги до конкретного варіанту можна визначити наступним чином (де `student_id` це номер варіанту студента): 25 | ```python 26 | 27 | >>> from itertools import product 28 | >>> student_id = ... 29 | >>> print(list(product( 30 | >>> ('python 3.8.*', 'python 3.7.*', 'python 3.6.*'), 31 | >>> ('venv + requirements.txt', 'virtualenv + requirements.txt', 'poetry', 'pipenv') 32 | >>> ))[(student_id - 1) % 12]) 33 | 34 | При попередньому узгодженню з викладачем можна 35 | 36 | ## Хід роботи 37 | 38 | 1. Створити репозиторій у відповідній платформі (наприклад GitHub) та склонувати його, створити нову гілку 39 | 2. Інсталювати Python обраної версії за варіантом за допомогою [pyenv](https://github.com/pyenv/pyenv) 40 | 3. Створити та активувати віртуальне Python середовище з інтерпретатором версії згідно з варіантом; якщо директорія віртуального середовища створена в директорії проекту, додати її в файл `.gitignore` (саме віртуальне середовище не має комітитись в репозиторій) 41 | 4. Добавити `Flask` в залежності проекту та інсталювати його (виконується по-різному залежно від варіанту) 42 | 5. Реалізувати адресу `api/v1/hello-world-{номер варіанту}`, що буде відповідати текстом `Hello World {номер варіанту}` з HTTP статус кодом відповіді `200`; Запустити та перевірити правильність виконання 43 | 6. Запустити проект використовуючи WSGI сервер (gunicorn, uWSGI чи інший на вибір) 44 | > На вибір бо, наприклад, gunicorn не підтримує Windows 45 | 7. Закомітити та запушити створені файли в репозиторій у попередньо створену гілку 46 | 8. Злити гілку з кодом лабораторної з гілкою `master` за допомогою Pull request (він жє ж Merge request) у відповідній платформі ([приклад виконання](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request) для GitHub) 47 | 48 | 9. У файлі `README.md` описати інструкцію по розгортанню проекту 49 | 50 | ## Критерії оцінювання 51 | 52 | 1. Git 53 | * Перевірити наявність репозиторію на відповідній платформі (GitHub, GitLab чи іншій) 54 | * Перевірити наявність комітів 55 | > Командою `git log HEAD` або через візуальний інтерфейс 56 | 2. Python 57 | * Перевірити чи версія Python у активованому віртуальнму середовищі відповідає варіанту 58 | > Виконання команди `python --version` має видавати відповідну версію 59 | * Перевірити наявність віртуального середовища 60 | > Виконання команди `which python` (`where python` у Windows) має вказувати на інтерпритатор у віртуальному середовищі а не на системний, коли віртуальне середовище активоване 61 | * Перевірити що `Flask` вказаний в залежностях 62 | > Залежності можуть вказуватись у файлі `requirements.txt` або у іншому файлі залежно від інструменту управління залежностями 63 | 3. Реалізація адреси 64 | * Студент має запустити проект WSGI-сервером (не через`flask run`) 65 | * GET запит на `http://localhost:{порт}/api/v1/hello-world-{номер варіанту}` віддає текст "Hello World {номер варіанту}" та має HTTP статус код 200 66 | > Перевірити виконанням `curl -v -XGET http://localhost:5000/api/v1/hello-world-3` або у браузері 67 | 4. Студент має описати процес розгортання проекту з файлу `README.md` 68 | -------------------------------------------------------------------------------- /Lab 5/README.md: -------------------------------------------------------------------------------- 1 | # Проектування REST API 2 | 3 | Проектуючи REST API визначають: 4 | * сутності, що містяться в системі 5 | * операції, які можна виконувати над тими чи іншими сутностями 6 | * які HTTP методи використовуються до яких операцій 7 | * структура запитів та відповідей для тих чи інших операцій 8 | * які HTTP статус коди повертаються в тій чи іншій ситуації 9 | * як відбувається авторизація 10 | 11 | Всі ці рішення документуються, щоб всі члени команди розуміли всі деталі API, яке потрібно реалізувати. Також така документація може використовуватись користувачами API щоб розуміти які операції можна виконувати, які дані передавати в запитах, які дані очікувати у відповідь і т.д. 12 | 13 | В процесі реалізації спроектованого REST API, особливо при засосуванні методології розробки Agile, деякі його деталі можуть змінюватись, тоді документація змінюється відповідно. 14 | 15 | REST API можна описувати різними способами, однак найпопулярнішим є стандарт [OpenAPI](https://swagger.io/specification/) (колишня Swagger Specification). OpenAPI специфікації описуються в форматі YAML або JSON. 16 | 17 | В даній лабораторній роботі потрібно визначити як буде виглядати API системи згідно з варіантом та описати його в форматі OpenAPI версії 3. 18 | 19 | ## Варіанти 20 | 21 |

Варіант 1. Створити сервіс переказу коштів між користувачами, кожен користувач має власний гаманець та можливість переказувати чи отримувати кошти від іншого користувача.

22 |

Варіант 2. Створити сервіс коротких (404 символи) заміток (із тегами) для кожного користувача із можливістю перегляду, редагування і видалення, а також надавати доступ редагувати замітку іншими користувачами (до 5 користувачів). Також надати можливість бачити статистику користувача, скільки повідомлень, коли редаговані і ким.

23 |

Варіант 3. Створити сервіс оголошень + CRUD із двома рівнями повідомлень. Оголошення повинні бути локальними та публічними. Локальні оголошення тільки для користувачів, що знаходяться в тому ж місці. Публічні для всіх, навіть для не користувачів сервісу.

24 |

Варіант 4. Створити сервіс кредитування користувачів на основі даних, що користувач вводить при реєстрації, кошти для кредитування видаються із бюджету 517 000 грн ставка 30%. Також реалізувати можливість погашення кредиту.

25 |

Варіант 5. Написати сервіс статей (2000 символів). Статті є публічними для всіх, зареєстровані користувачі можуть редагувати статтю та очікувати на схвалення її модераторами (користувачі із більшими правами). Передбачити варіант редагування, коли стаття на розгляді модератором, а інший користувач її теж редагує. Модератори мають бачити статті, які очікують їх схвалення.

26 |

Варіант 6. Написати сервіс простий інтернет магазин. Користувачі можуть купувати один із 8 товарів, які є в обмеженій кількості на складі, не допустити можливості продажу одного і того ж товару кільком користувачам.

27 |

Варіант 7. Створити сервіс для резервування аудиторій на певну дату час та проміжок часу від 1 години до 5 днів. Користувачі мають можливість резервувати аудиторії, а також редагувати, скасовувати та видаляти їх. Застерегти користувачів від накладок (два користувачі не можуть зарезервувати аудиторію на певний період час)

28 |

Варіант 8. Написати сервіс для купівлі та бронювання квитків на концерти, події і т.д. Користувачі мають можливість купувати квиток, бронювати квиток, скасовувати бронь. Унеможливити купівлю чи бронювання одного і того ж квитка кількома користувачами.

29 |

Варіант 9. Написати сервіс для створення плейлистів. Користувач може мати як приватні (видимі тільки для нього), так і публічні (видимі для всіх) плейлисти. Публічні плейлисти можуть редагувати всі користувачі.

30 |

Варіант 10. Створити сервіс для календаря подій. Користувач має можливість створювати подію, редагувати її, видаляти, долучати інших користувачів до події, переглядати перелік всіх створених події, та подій до яких він долучений.

31 |

Варіант 11. Створити сервіс для проведення онлайн занять. Повинні бути користувачі двох рівнів – викладачі та учні. Викладачі можуть створювати, видаляти, редагувати курс, переглядати перелік створених курсів, долучати студентів до курсу. До курсу може бути долучено не більше 5 студентів. Студенти можуть переглядати всі дані лише тих курсів, до яких вони долучені. Також студенти можуть надсилати на участь у якомусь курсі, а викладач має можливість прийняти або відхилити запит.

32 |

Варіант 12. Створити сервіс для збереження та редагування рейтингу студентів. Для зберігання даних про студента використовувати json. Також реалізувати можливість отримання списку кращих за рейтингом студентів.

33 |

Варіант 13. Написати сервіс для роботи з сімейним бюджетом на спільному рахунку. В сім’ї повинно бути не менше 3 людей. Кожен користувач має можливість переглядати бюджет, додавати в нього кошти, знімати кошти на свій персональний рахунок. Також передбачити можливість збереження та виведення переліку витрат та доходів як сім’ї загалом, так і кожного її учасника.

34 |

Варіант 14. Створити сервіс для прокату авто. Користувачі сервісу можуть бути двох рівнів – адміністратори та пасажири. Адміністратори можуть додавати та видаляти авто із системи, редагувати інформацію про авто. Пасажири можуть переглядати каталог та бронювати авто на певний час.

35 |

Варіант 15. Написати сервіс для роботи аптеки. Провізор може додавати препарати в базу, видаляти, редагувати інформацію про них. Користувач може переглядати інформацію про препарати, здійснювати купівлю, якщо немає препарату в наявності, то його можна додати в попит.

36 |

Варіант 16. Написати сервіс для роботи кінотеатру. Адміністратор може складати розклад показу фільмів, з урахуванням тривалості фільму та зайнятості залу, редагувати розклад, видаляти та додавати фільми.

37 |

Варіант 17. Свій варіант (після узгодження з викладачем)

38 | 39 | ## Рекомендації 40 | 41 | * OpenAPI специфікації досить великі за ромізром, тому для спрощення процесу створення нової API можна розпочати з прикладу специфікації "Swagger Petstore" з [Swagger Editor](https://editor.swagger.io). Даний приклад використовує специфікацію OpenAPI 2, його можна конвертувати в OpenAPI 3 засобами Swagger Editor (Editor / Convert to OpenAPI 3). Після конвертації в OpenAPI 3 даний приклад можна використати для створення власної специфікації, при цьму варто старатись обмежитись мінімально необхідною специфікацією, без копіювання непотрібних елементів з прикладу. 42 | 43 | ## Хід роботи 44 | 45 | 1. Визначити набір сутностей, що будуть в системі та описати які зв'язки будуть між ними та які операції над ними можна виконувати 46 | 2. Створити файл `swagger.yaml` з описом API у форматі OpenAPI 3 47 | 3. Перевірити валідність створеного `swagger.yaml` за допомогою [Swagger Editor](https://editor.swagger.io). 48 | 49 | ## Критерії оцінювання 50 | 51 | 1. Студент має описати словами створену специфікацію REST API 52 | 2. Файл `swagger.yaml` має містити валідний опис API в форматі OpenAPI 3 53 | > Перевірити валідність можна за допомогою [Swagger Editor](https://editor.swagger.io) 54 | 3. Використані коректні HTTP методи та HTTP статус коди для тих чи інших операцій 55 | > Перевірити у візуалізації специфікації Swagger Editor 56 | 4. Окрім опису відповіді при успішному виконання також мають описуватись відповіді при тих чи інших помилках 57 | > Перевірити опис відповідей при HTTP статус кодах відмінних від 200 58 | --------------------------------------------------------------------------------