Django Rest Framework для начинающих: создаём API для чтения данных (часть 1)

[TurboKach]

Отличная подробная статья с подкапотной разборкой!
В отличие от Django, у DRF не такая подробная дока с разбором всех возможных юз кейсов, так что статья в тему.

[Benjamin_Button]

Круто! Я тож занимаюсь на Я.Практикуме как раз на 9 спринте с DRF, очень актуально)

[saintbyte]

Много лишнего , есть же ModelSerializer и ModelViewSet

[StasGaranzha]

Задача статьи — дать начинающим ребятам понимание того, как устроен DRF и, прежде всего, процесс сериализации. Поэтому я и отталкиваюсь от базового класса
restframework.Serializer. Кажется, что если усвоить, как работает базовый класс, то переход на более высокий уровень абстракции (каким выступает класс-наследник ModelSerializer) будет несложным и понятным. В статье есть оговорка о существовании ModelSerializer и поясняется, почему мы сейчас его не рассматриваем.

[saintbyte]

Проблема в том что сейчас начинающие разработчики начитаются и применят затем это будет продолжаться пока тим лид 5 раз по рукам не даст. Вы недооцениваете силу привычки.

[StasGaranzha]

Если начинающий разработчик начитается и поймёт, как в целом устроена работа конкретного фреймворка, и на основе этого знания будет применять более высокие уровни абстракции (тот же ModelSerializer, применение которого, кстати, не универсально), никто ему по рукам не даст. А вот если он начнет применять сразу тот же ModelSerializer, не понимая, откуда растут ноги у этого инструмента, то вполне возможно. В любом случае, как написано во введении, это только первая статья, отдельно о ModelSerializer я обязательно расскажу.

[eandr_67]

Остался нерассмотренным один вопрос: в каких случаях целесообразно использовать именно Python для написания REST API?
Любой инструмент предназначен для решения определённого круга задач, вне которого использование этого инструмента нерационально. И хотелось бы понять, для какого круга задач Django Rest Framework эффективнее PHP или Go REST-фремворков?

[simon_db]

Исп. DRF, если вся логика — это просто сделать быстро простой CRUD сервис для работы с таблицами БД, без особой логики. Реализация в этом случае будет предельно простая. Из коробки будет пагинация, фильтрация, сортировка, работа с М2М связями, валидация, пермишены и т.п.

Если у вас приложение достаточно сложное и имеет много внутренних процессов, обработок, если ваша схема REST API != схема таблиц базы данных, то тут уже сложнее, но тоже можно.

Я хорошо не знаком с фреймворками на GO, но из того, что я знаю, писать потребуется сильно больше всего. Это хорошо, если приложении обещает быть сложным, вы сами сконструируете из небольших компонентов именно то, что вам нужно, не подстраиваясь под особенности работы DRF, Django ORM и т.п. Иногда они сильно мешают.

[bazilevichla]

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