Django: Есть ли смысл разделять вызовы api на собственные конечные точки url?
Я думаю, что вы ищете практические вопросы, поэтому я не буду акцентировать внимание на некоторых (возможно) теоретических аспектах REST по сравнению с другими подходами.
Самая большая проблема, которую я провожу, заключается в том, что клиентам этого сервиса нужно будет научиться использовать эти звонки и адаптироваться к вашему индивидуальному подходу. Если вы также пишете на стороне клиента, это может показаться не проблемой, но даже в этом случае вы теряете возможность использовать существующие библиотеки для поддержки клиентов. Существуют также потенциальные проблемы с брандмауэрами и т. д. Это может сработать, но это просто необычно, и если вы заставляете кого-то еще иметь дело с этим подходом, будьте готовы к жалобам. Еще одна вещь, которую вы теряете, — это возможность использовать стандартизированные инструменты документации. Подробнее об этом в конце.
Другая потенциальная проблема, с которой вы можете столкнуться, заключается в том, что если вы когда-нибудь захотите разделить эти действия на отдельные развертывания и/или реализации, у вас будет гораздо более сложная ситуация. Легко настроить внешний балансировщик нагрузки или обратный прокси-сервер, который направляет один шаблон URL на сервер A, а другой — на сервер B. Можно ли сделать то же самое с заголовками? Возможно, но может сузить ваши варианты, быть менее производительным и/или создать дополнительную сложность.
Я бы порекомендовал вам взглянуть на другую структуру для веб-сервисов. Я уже давно использую FastAPI , и он предлагает множество полезных функций для сервисов RESTful. Я не собираюсь перечислять все функции, но главное для вас то, что он имеет чрезвычайно приятный синтаксис для объявления вашего API REST и может автоматически генерировать OpenAPI документы, размещающие страницы swagger и redoc на вашем хосте с минимальными усилиями для простые конечные точки. Для более сложных требований он работает с Pydantic для синтаксического анализа/записи и проверки, и эти модели также включаются в спецификацию openapi.json. Я думаю, если вы попробуете это, вы увидите, что вы упускаете то, что прокладываете свой собственный путь таким образом.
Прикрепляю к посту несколько видео по теме: