Структура рабочих каталогов для проекта Django-Python, используемого только в качестве бэкенда API

Фреймворк Django REST должен работать для вашего проекта. Он поддерживает сериализацию, проверку подлинности и общую документацию (Swagger), необходимую для ваших ~15 конечных точек, о которых вы говорите.

Типичная структура проекта

my_project/
│
├── manage.py                  # Django's command-line utility
│
├── project_config/            # Project settings directory
│   ├── __init__.py
│   ├── settings.py            # Project settings
│   ├── urls.py                # Project-level URL routing
│   ├── asgi.py                # ASGI config for deployment
│   └── wsgi.py                # WSGI config for deployment
│
├── api/                       # Main API app
│   ├── __init__.py
│   ├── urls.py                # API-specific URL routing
│   ├── views/                 # Your "controllers" in Django terms
│   │   ├── __init__.py
│   │   ├── user_views.py      # User-related endpoints
│   │   ├── product_views.py   # Product-related endpoints
│   │   └── ...
│   │
│   ├── serializers/           # Handle JSON conversion & validation
│   │   ├── __init__.py
│   │   ├── user_serializers.py
│   │   ├── product_serializers.py
│   │   └── ...
│   │
│   ├── models/                # Database models (ORM)
│   │   ├── __init__.py
│   │   ├── user.py
│   │   ├── product.py
│   │   └── ...
│   │
│   ├── services/              # Business logic layer
│   │   ├── __init__.py
│   │   ├── user_service.py
│   │   ├── product_service.py
│   │   └── ...
│   │
│   └── tests/                 # Test directory
│       ├── __init__.py
│       ├── test_user_api.py
│       ├── test_product_api.py
│       └── ...
│
├── utils/                     # Shared utilities and helpers
│   ├── __init__.py
│   ├── permissions.py         # Custom permissions
│   ├── pagination.py          # Custom pagination
│   └── ...
│
├── requirements.txt           # Project dependencies
│
└── .env                       # Environment variables (not in version control)

Эта структура соответствует вашей .Терминология СЕТИ следующая.

1. Controllers: В Django они называются "представлениями" и находятся в api/views/ directory.

2. Business Logic: Ваш каталог api/services/ - это то место, где живет бизнес-логика.

3. Data Layer: Django ORM models в api/models/ управляет вашим уровнем данных.

Сопоставление со слоями .NET

Обратитесь к моему блогу, в котором есть шаги, которые я когда-то делал, для упрощения настройки структуры каталогов серверной части Django API. - Настройка вашего проекта Django

Также хорошая ссылка - https://plainenglish.io/blog/how-to-structure-your-django-project-a5d50333a644

На всякий случай: Соглашения об именовании конечных точек RESTful API

1. Используйте строчные буквы Используйте строчные буквы во всех URL-адресах API для согласованности, удобства ввода и минимизации путаницы в системах, чувствительных к регистру, что улучшает SEO и удобство работы с пользователями. Пример: '/api/v1/пользователи', '/api/v3/заказы'

2. Используйте существительные, избегайте глаголов (грубые функции) Разрабатывайте API-интерфейсы как ресурсоориентированные, используя существительные для обозначения ресурсов (например, "/пользователи", "/продукты"), а не глаголы (например, "/Получить пользователей", "/Обновить продукты"). Пусть HTTP-методы (GET, POST, PUT, DELETE) определяют действия. Правильно: "/пользователи", "/продукты" Избегайте: "/получить-пользователей", "/обновить-продукты"

3. Используйте уникальные и интуитивно понятные имена для иерархии URI Используйте существительные в единственном числе для обозначения архетипов ресурсов документа (например, единого объекта), чтобы создать четкие, лаконичные и оптимизированные для SEO URL-адреса, которые будут понятны как разработчикам /QA, так и поисковым системам. Пример: "/rest-api/v1/users", "/api/v1/orders" Используйте понятные и описательные названия. Избегайте сленга или сокращений, которые могут быть непонятны другим. Пример: используйте "order-history" вместо "ord-hist" или "prod-cat", чтобы было понятнее.

4. Используйте косую черту (/) для обозначения иерархии URI Упорядочивайте свои URL-адреса, используя косые черты, чтобы создать четкую иерархию (например, "/пользователи", "/users/{id}", "/заказы"). Избегайте косых черт в конце (например, не должно быть "/пользователи/", должно быть "/users"), чтобы предотвратить двусмысленность, обеспечить согласованность и избежать проблем с дублированием контента в SEO. Пример: '/пользователи', '/users/123', '/заказы'

5. Используйте дефисы (-) для разделения слов для удобства чтения Используйте дефисы для разделения слов в названиях конечных точек для лучшей читаемости и поисковой оптимизации (например, "/профиль пользователя", "/история заказов"). Избегайте подчеркивания (_) и заглавных букв, так как они менее удобочитаемы и не подходят для SEO. Пример: "/профиль пользователя", "/история заказов", "/категория продукта"

6. Используйте параметры запроса для фильтрации и предоставления подробной информации Используйте параметры запроса для фильтрации, сортировки или предоставления определенных наборов данных с сервера (например, "/products?категория=электроника и сортировка=цена"). Эти параметры могут включать сортировку, фильтрацию и разбивку по страницам для повышения гибкости. Представьте сложную фильтрацию в виде параметров запроса (например, '/products?цена>100&sort=desc'). Убедитесь, что специальные символы закодированы в URL-адресе для надежности. Пример: '/товары?категория=электроника&сортировка=цена', '/пользователи?роль=администратор&ограничение=5'

7. Включите фильтрацию, сортировку и разбивку на страницы Реализуйте разбивку на страницы с использованием параметров ограничения и смещения или страницы (например, '/products?limit=10&offset=20', '/products?page=1&limit=5') для управления большими наборами данных и предотвращения перегрузки клиентов или серверов. Включите фильтрацию и сортировку с помощью параметров запроса (например, '/products?категория=электроника&сортировка=бренд'). Пример: '/products?ограничение=10&смещение=20', '/продукты?страница=1&ограничение=5', '/пользователи?роль=администратор&ограничение=5'

8. Избегайте использования URL/экранирующих символов URL Избегайте в своих URI таких символов, как пробел (%20), $, &, <, >, [], |, ", ', ^. Эти символы могут привести к путанице или создать проблемы в определенных средах, поэтому лучше полностью избегать их в путях к конечным точкам.

9. Не используйте расширения файлов Избегайте добавления расширений файлов, таких как .json, .xml или .html, к маршрутам API. Используйте HTTP-заголовки (Accept и Content-Type) для согласования содержимого. Пример: "/rest-api/v1/users" (не "/rest-api/v1/users.json" или "/rest-api/v1/users.xml")

10. Используйте управление версиями API для SEO и масштабируемости Реализуйте управление версиями API в URL-адресах, чтобы поддерживать обратную совместимость по мере развития вашего API. Четко указывайте номера версий в URL-адресе для наглядности и удобства поиска. Пример: '/rest-api/v1/users', '/api/v2/users', 'rest-api.company.com/v1/users'

11. Будьте последовательны во всех аспектах SEO и юзабилити Поддерживайте единые правила именования, сортировки, фильтрации и разбивки на страницы во всех конечных точках API, чтобы создать интуитивно понятную, удобную для SEO структуру, по которой поисковые системы и разработчики смогут легко перемещаться и индексировать. Пример: '/rest-api/v1/products?sort=название', '/rest-api/v1/products?sort=цена', '/rest-api/v1/products?sort=описание'

12. Используйте описательные имена параметров Убедитесь, что параметры запроса являются описательными и непротиворечивыми в вашем API. Для наглядности используйте общие термины, такие как статус, тип, идентификатор, категория и сортировка. Пример: '/api/v1/products?категория=электроника и сортировка=название', '/rest-api/v1/users?идентификатор=123'

13. Рассмотрим взаимосвязи ресурсов для иерархий Используйте вложенные ресурсы для представления взаимосвязей между объектами, создавая иерархические, оптимизированные для SEO URL-адреса, которые поисковым системам легко просматривать, а разработчикам - понимать. Пример: '/api/v1/пользователи/123/заказы', '/rest-api/v1/продукты/456/отзывы'

14. Используйте коды состояния HTTP и обработку ошибок Используйте стандартные коды состояния HTTP для указания результатов запроса API, улучшая SEO и удобство использования для разработчиков /QAS, которые ищут документацию: '200 OK' - Успешный запрос GET, PUT или POST '201 Создан' - Новый ресурс успешно создан '400 Неверных запросов" - Неверные параметры запроса с четкими сообщениями об ошибках "404 не найден" - Запрошенный ресурс не найден "Ошибка сервера 500" - проблема на стороне сервера с подробными ответами на ошибки для устранения неполадок. Предоставляйте четкие, описательные сообщения об ошибках в тексте ответа (например, сообщение, код, подробные сведения), чтобы улучшить возможность поиска документации по API и удобство работы с ней для пользователей. { "статус": 400, "сообщение": "Недопустимое значение параметра", "подробности": "Идентификатор пользователя должен быть положительным целым числом", "код": "НЕДОПУСТИМЫЙ параметр". }

15. Защитите свой REST API с помощью аутентификации Используйте токены на предъявителя для аутентификации API (например, 'Authorization: Bearer '). Рассмотрите возможность использования стандартных протоколов аутентификации, таких как OAuth 2.0, для улучшения управления безопасностью. Заголовок примера: Авторизация: Предъявитель eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Лучшие практики обеспечения безопасности:

1. Всегда используйте HTTPS
2. Реализуйте ограничение скорости
3. Установите срок действия токена
4. Проверьте все входные данные
5. Используйте защищенные заголовки