Как создать REST API на Python с помощью микрофреймворка Flask


КРЕДИТНОЕ ИЗОБРАЖЕНИЕ: Эдмон Атто

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

Колба с другой стороны является питон микрофреймворк, который используется для разработки веб-приложений.

я построил API вокруг приложения под названием BucketList. Приложение позволяет пользователю Собязанность рэд, Uдата и Дудалить (CRUD) ведро и элементы внутри. В этой статье я опишу процесс, через который я прошел при разработке API, и поделюсь несколькими фрагментами кода строго для примера. Код живет Гитхаб и вы можете найти его здесь.

Начальная структура папок

api/ 
  |- app 
    |- auth 
    |- bucket 
    |- bucketitems 
    |- __init__.py 
    |- config.py 
    |- models.py 
    |- views.py 
 |- .gitignore 
 |- manage.py 
 |- run.py 
 |- requirements.txt 
 |- README.md

Выше моя исходная структура папок с api как имя папки приложения. Логика приложения находится в app папка. В папке приложения есть три фляги Чертежиавторизация, ведро и ведро.

  • Схема аутентификации содержит логику для аутентификации и авторизации приложения.
  • Схема корзины содержит логику выполнения операций Bucket CRUD.
  • План Bucketitems содержит операции CRUD для элементов сегмента.

Изучение файловой структуры

  1. __init__.py Файл содержит код для настройки приложения Flask и регистрации различных Blueprints в экземпляре приложения.
  2. config.py файл содержит различные параметры конфигурации приложения, которые относятся к тестированию, разработке и производству. В зависимости от среды, в которой запускается приложение, используется другая конфигурация.
  3. models.py файл содержит различные модели баз данных, users , buckets , bucketitems и другие модели.
  4. views.py содержит общие маршруты приложения.
  5. .gitignore файл содержит файлы, которые не должны добавляться и отслеживаться Система контроля версий(ВКС) в этом случае Гит.
  6. manage.py файл содержит команды приложения, определенные вами и предоставленные Flask-скрипт расширение.
  7. requirements.txt файл содержит ссылку на расширения приложений и их версии. Он генерируется при запуске pip freeze > requirements.txt в терминале.
  8. README.md файл уценки содержит любое описание или информацию, которую разработчик предоставляет пользователям приложения.

Разработка через тестирование

Разработка через тестирование(TDD) является хорошей практикой при написании кода. По моему опыту, это позволяет вам подумать о различных аспектах функциональности кода, который вы собираетесь написать, а затем заранее придумать тесты, прежде чем писать функциональность функции. Позже вы пишете код и убеждаетесь, что ваши ранее не пройденные тесты пройдены. Если вы позже что-то измените в своем коде, просто запустите тесты и убедитесь, что ничего не сломано. Если они терпят неудачу, то вы знаете, что вам нужно исправить ошибку.

Во время разработки API я практиковал TDD в некоторых частях реализации. Позже я продолжил и написал тесты, охватывающие не менее 97% всего написанного мной кода.

Я использовал расширение Flask под названием Колба-тестирование за написание всех моих тестов приложений, и я запускаю тесты, используя пакет Python, называемый нос.


Аутентификация на основе токенов

Вся аутентификация API построена с использованием Веб-токен Json(JWT) система аутентификации. Токены JWT обеспечивают безопасный способ представления требований между двумя сторонами.

Я использовал пакет Python под названием Покидать для кодирования и декодирования JWT. Когда пользователь регистрируется или входит в систему, ему назначается токен. Срок действия этого токена истекает по истечении заданного периода времени или при выходе пользователя из системы. Когда пользователь выходит из системы, токен становится недействительным, заносится в черный список и добавляется в таблицу черного списка в базе данных.

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


Управление версиями

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

Для большей части разработки я использовал (симулировал) Gitflow-рабочий процесс. Этот рабочий процесс предполагает создание develop ответвление от master ветку, а затем создать feature ответвления от ветки разработки. Самый важный вывод из этого рабочего процесса заключается в том, что master ветка должна содержать только «рабочий» код (код, готовый к выпуску).

Я также использовал Github Pвсе запросы(PR), чтобы мои коллеги могли просмотреть и прокомментировать мой код, прежде чем я смогу объединить его в develop ответвляться.


Сохранение данных

Как вы знаете, большинству приложений приходится так или иначе хранить пользовательские данные. Мой API использует postgresql база данных для сохранения данных пользователей, в частности, учетных данных пользователя для входа, сегментов и их элементов.

я использовал Колба-Sqlalchemy расширение для взаимодействия с базой данных. В основном это позволило мне создать классы модели пользователя, ведра и элементов ведра.

Я также использовал Flask-миграция расширение для создания миграций для базы данных. Миграция базы данных похожа на «контроль версий» для схемы базы данных.

Я использовал другое расширение Подделка для создания фиктивных данных для приложения, чтобы я мог протестировать некоторые функции, такие как api-pagination которые несколько требуют много данных.


Конфигурация

API работает в трех средах development , testing а также production . Чтобы переключать конфигурации между этими разными средами, я создал config.py файл для обработки всех различных переменных для каждой среды.

Активная конфигурация управляется APP_SETTING переменная конфигурации, для которой задана одна из трех конфигураций в зависимости от среды.


Непрерывная интеграция

Я новичок во всей концепции непрерывной интеграции (CI), поэтому я укажу только на один инструмент (Трэвис Си), который я использовал во время разработки.

Я использовал Travis для запуска моих сборок всякий раз, когда я нажимал коммит, ветку или делал PR. Трэвис также дал мне возможность через .travis.yml файл для настройки базы данных postgres, чтобы при запуске тестов не возникало ошибок для тестов, требующих базы данных. После успешного запуска тестов детали покрытия были отправлены на комбинезон для дальнейшего анализа.


Добавление значков в ваш репозиторий

Значки репозитория направляли, а также мотивировали меня во время разработки. Я добавил Трэвис, покрытие(комбинезон), Лучший код а также Кодацизначки.

  • Значок Трэвиса показывал, прошла ли сборка или нет.
  • Значок покрытия показывал процентное покрытие теста.
  • Bettercode показал качество кода по десяти атрибутам
  • Значок кода показал общее качество кода.

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

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


Окончательная структура папок

Во время разработки многое изменилось, как и структура папок приложения. В конце разработки структура моей папки изменилась на приведенную ниже.

api/ 
  |- app 
    	|- auth 
        |- bucket 
        |- bucketitems 
        |- docs 
        	|- static 
            	|- js 
                	|- apairy.js 
                |- favicon 
            |- templates 
            	|- docs 
                	|- index.html 
        |- __init__.py 
        |- config.py 
        |- models.py 
        |- views.py 
  	|- migrations 
    |- tests 
    |- .coveralls.yml 
    |- .travis.yml 
    |- run.py 
    |- Procfile 
    |- .gitignore 
    |- manage.py 
    |- requirements.txt 
    |- README.md

я добавил docs план для обработки всего, что связано с документацией API, включая apiary.js файл, содержащий код для встраивания документации Apiary API, значок сайта и index.html файл.

tests папка содержала тесты приложений, migrations папка содержала файлы миграции модели и Procfile содержал Героку конфигурации.

Хостинг

Наконец, после разработки мне пришлось развернуть свой API. Я решил разместить свое приложение на Героку это платформа, которая позволяет размещать приложения, написанные на различных языках программирования.

Procfile в приведенной выше структуре папок содержались конфигурации, которые позволяли Heroku запускать приложение. Эти конфигурации включали gunicorn config сервера и config для создания таблиц базы данных.

Вы можете найти мой пост о размещении этого API на Heroku. здесь .

API доступен здесь Вы можете проверить это.

Весь код размещен здесь.

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован.