huhu’

Si vous me cherchez, j’suis déjà dehors… ->[]
;-)

De surcroît, la sérialisation (qui n’est pas que du JSON, mais admettons que le XML n’interesse pas), ne se fait pas qu’à la sortie. Il se fait aussi en entrée. Hors, forcer ton client à envoyer du json plutôt qu’un query string ou du form encoded, c’est limiter tes clients qui peuvent être écrits dans des tas de langages dans lesquels l’un est plus facile que l’autre. Le framework autorise tout ça de manière transparente, et gratuitement.

Par ailleurs, DRF permet facilement la sérialisation des modèles de l’ORM, c’est autant de travail en moins, mais également de la pagination. C’est un vrai plus. Les sérialiseurs servent également à encapsuler la validation de données, qui permet de réutiliser cette logique à bien des endroits.

Il est vrai que c’est plus lourd et verbeux que flask (la concision et la légèreté est le point fort de ce micro framework), mais ce que tu en obtiens n’est pas comparable. De plus, avec le principes des viewsets, DRF permet d’écrire des vues REST CRUD complètes sur une ressource en base de données de manière très très propre (le GET, le POST, le PUT et le DELETE sont respectés) en quelques lignes, avec une documentation autogénérée, dynamique et navigable via le browser. Ce genre de choses est une vraie merveille.

Bref, même sur des gros projets, tout dépend du besoin bien sûr, je préfère la souplesse de Flask. Après quand tu as capitalisé dessus depuis un moment et que tu as déjà tes propres validators pour tes model, ta propre surcouche au JSON codec, (bin ouais les datetime ne sont pas convertis automatiquement), ta propre stack Auth, etc, c’est sûr que c’est plus simple aussi.

Mais j’ai regardé django rest framework vite fais, franchement je trouve qu’il y a beaucoup de verbatim autour des data (model + serializer) et que la façon de faire les view + route n’est pas hyper souple. Si c’est pour galérer dès qu’il faut toucher aux headers ou autre subtilités, non merci.