Eu me rendo: Django REST Framework
Confesso que nunca fui muito simpático ao Django REST Framework. Antes de adotá-lo tive a oportunidade de explorar outras opções, como o Restless, e admito que sempre havia algo faltando, ou algum esforço extra necessário para obter alguma funcionalidade que já vinha embutida no DRF.
Comecei a aceitar a sua natureza "baterias inclusas" após me distanciar do desenvolvimento Python. Sob uma ótica diferente, compreendi o papel do DRF, e fiz as pazes com esse sentimento de confiar em uma biblioteca (supostamente) complexa para construir APIs (teoricamente) simples. Afinal, se "ser bloated" for um argumento decisivo, não escolheríamos Django para escrever APIs (principalmente em um contexto de microserviços).
Motivação
É claro que a minha atual simpatia pela ferramenta não se deve apenas ao fato de eu tê-la "aceitado". Pura ignorância da minha parte não ter compreendido antes todos os aspectos positivos que o projeto possui, e todas as facilidades que ele proporciona aos seus usuários.
Patrocinado
O que faz do REST Framework um projeto interessante é, para começo de conversa, que ele é financiado colaborativamente, com empresas do calibre de Sentry e DigitalOcean fazendo parte da lista de patrocinadores. Essa característica faz com que a biblioteca tenha um long-term mais provável, uma vez que os esforços de desenvolvimento são financiados. Além disso, releases são mais substanciais e frequentes.
Leia mais sobre como patrocinar o projeto.
Autenticação
Lidar com autenticação "from scratch" é no mínimo error prone. O framework já possui uma série de mecanismos de autenticação built-in (como BasicAuthentication, SessionAuthentication e TokenAuthentication), e uma infinidade de integrações com third parties (como django-oauth-toolkit, django-rest-framework-simplejwt e djoser).
A possibilidade de mesclar mecanismos num mesmo recurso permite que você tenha uma API session based para o seu front-end em React (por exemplo), e o mesmo recurso ser capaz de servir acessos utilizando tokens, para um possível cliente mobile.
SQL & NoSQL
Os serializadores são um aspecto muito interessante da biblioteca. Além do trabalho de marshalling, eles também servem como validadores. Com o ModelSerializer todos os aspectos do seu modelo são "traduzidos" para a API, no melhor estilo Django Admin.
Mas existe também a possibilidade de escrita de seu própria classe serializadora ao herdar de serializers.Serializer. Isso traz flexibilidade para trabalhar com artefatos não relacionados com a ORM do Django.
E se HATEOAS for a sua praia, o HyperlinkedModelSerializer promove hyperlinks entre tais classes.
Developer eXperience
APIs escritas com o REST Framework ainda ganham a funcionalidade de "web browsable API". Com isso é possível navegar pelas definições da sua API (como endpoints, formatos e métodos) e interagir com a mesma através de uma interface amigável, pronta para ser compartilhada com outros desenvolvedores interessados em consumir a sua solução.
Uma outra opção é a geração de Swagger através do Django REST Swagger.
Praticidade
E meu argumento final é em torno de sua praticidade. Ter uma API REST em Django, com o DRF, leva minutos...
Algumas customizações poderão exigir um pouco mais de conhecimento da biblioteca, bem como um pouquinho de criatividade, mas nada que te impeça de proporcionar um serviço estável, bem escrito, e em baixíssimo tempo de desenvolvimento.
Leia mais sobre como customizar views.
Considerações finais
Talvez seja só devaneio, mas depois de trabalhar com Spring Boot para construção de APIs Java em um contexto de microserviços, foi que entendi o propósito do REST Framework. Deixar de lado essa "birra" com ele (supostamente) ser grande serviu para poder enxergar as qualidades da ferramenta.
Os pontos negativos ainda estão lá, e provavelmente você também vai achá-los quando estiver "entrincheirado" escrevendo a sua solução. Ainda assim, o DRF deve ser considerado como possível escolha para escrita de suas APIs em Python.
No próximo artigo falaremos de uma maneira prática sobre o framework.
Até lá.