melhores praticas para trabalhar com django rest framework

[willian firmino]

Boa tarde, vou trabalhar pela primeira vez com REST em dois projetos pequenos, dei uma passada no tutorial do django rest framework porém me deparei com tantas opções que fiquei meio perdido. Então, os meus projetos são relativamente simples basicamente CRUD com que contem relacionamentos, ForeignKeys, ManytoManys enfim, o frontend vamos implantar usando o Angular 4.

Na documentação: http://www.django-rest-framework.org/tutorial/5-relationships-and-hyperlinked-apis/

Neste trecho:

Dealing with relationships between entities is one of the more challenging aspects of Web API design. There are a number of different ways that we might choose to represent a relationship:

• Using primary keys.
• Using hyperlinking between entities.
• Using a unique identifying slug field on the related entity.
• Using the default string representation of the related entity.
• Nesting the related entity inside the parent representation.
• Some other custom representation.

REST framework supports all of these styles, and can apply them across forward or reverse relationships, or apply them across custom managers such as generic foreign keys

Já da uma ideia da quantidade de opções. a mesma coisa com Views e Serializers e Autenticação. Então minha pergunta, qual seria as melhores opções para trabalhar com esses meus projetos neste contexto Views e Serializers e Autenticação? para ajudar segue os models de cada um https://pastebin.com/D8YiLr03

Ficarei muito agradecido se alguém me ajudar com dicas, links, etc... mesmo nos models aceito sugestões.

[Marlysson Silva]

Não relacionado ao drf.. Mas nos teus modelos tem campos que seriam mais adequado um boolean field.. E outros uma foreignkey..

Só uma dica.

[willian firmino]

Olá Marlysson Silva, poderia me dizer quais, estou aberto a sugestões

2017-08-29 16:09 GMT-03:00 Marlysson Silva <marly...@gmail.com>:

Não relacionado ao drf.. Mas nos teus modelos tem campos que seriam mais adequado um boolean field.. E outros uma foreignkey..

Só uma dica.

--
Você está recebendo esta mensagem porque se inscreveu no grupo "Django Brasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasil+unsubscribe@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/d/optout.

[Sinval Júnior]

Willian,

Ideal é montar os recursos sempre pensando nas funcionalidade. Ainda mais quando este recursos envolvem várias tabelas. Não conheço o negócio que o modelo representa. Pensando rapidamente eu faria algo mais ou menos assim.

A vantagem de trabalhar assim é a facilidade de utilizar o @transaction.atomic 

class Agenda(viewsets.ModelViewSet):

    permission_classes = (MinhaPermissao,)

    def get_object(self):

        pass # validar permissão

    @list_route(methods=['post'])

    @transaction.atomic

    def create_agenda(self, request):

        pass

    @details_route(methods=['get'])

    @transaction.atomic

    def get_agenda(self, request):

        pass

    @list_route(methods=['get'])

    @transaction.atomic

    def list_agenda(self, request):

        pass

    @list_route(methods=['put'])

    @transaction.atomic

    def add_anexo(self, request):

        pass

A classe  MinhaPermissao [1] irá velificar se o usuário logado tem permissão para acessar a fucionalidade xxx. Outra questão importante é retirar usar campos UUIDField para não expor a PK e claro login com JWT.

1 - http://www.django-rest-framework.org/api-guide/permissions/

Ao encaminhar esta mensagem, por favor:
1 - Apague meu endereço eletrônico;
2 - Encaminhe como Cópia Oculta (Cco ou BCc) aos seus destinatários. Dificulte assim a disseminação de vírus, spams e banners.

#=================================================================+
#!/usr/bin/env python
nome = 'Sinval Júnior'
email = 'sinvalju arroba gmail ponto com'
print nome
print email
#==================================================================+

--
Você recebeu essa mensagem porque está inscrito no grupo "Django Brasil" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasil+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

[willian firmino]

Sival, "Não conheço o negócio que o modelo representa." focando no model de ordem de serviços, é um sistema simples para registrar ocorrências de infraestrutura urbana de uma prefeitura, vão registrar reclamações a abrir chamados como por exemplo: buracos na rua, bueiro entupido ou sem tampa, entulhos na rua, etc... Então, são tantas opções para se trabalhar com django rest framework que quem vai começar fica completamente perdido como eu estou.

[Marlysson Silva]

Ok, lembrando que essas sugestões são na minha visão :D .

Na classe RecursosHumanos

No campo funcionário que está usando um CHOICES para verificar se é funcionário ou não.. Poderia usar um BooleanField para detectar isso..E se quiser a versão string dela, bastaria criar uma property tipo:

@is_funcionario_str(self):
    return "Sim" if self.is_funcionario else "Não"

Por que você tem essas classes : CoordenadorPauta e PessoasEnvolvidasAgenda herdando de RecursosHumanos sendo que essas classe não possuem nenhum atributo que as diferencie da classe mãe..

Poderia ter um choices para determinar a função/tipo/utilidade do RecursoHumano determinado.. e se tiverem comportamentos diferentes.. aí sim cria uma classe herdada..

Na classe DepartamentoSetor

No campo tipo poderia deixar o choices para 0 ou 1 , deixar o max_length pra 1 e o default.... por que 3? sendo que não possui nenhum número..

Classe OrgaoDemandante:

Os estados poderiam ser uma entidade.. e fazer os relacionamento entre eles através de um OneToOneField ( pelo que to analisando até aqui.. o orgão seria ligado à somente um estado. )

Os choices poderiam ser definidos sendo o primeiro valor um inteiro ( o que será guardado no banco ) e o segundo campo sendo a representação ( que o que poderia ser mostrado na tela. )

Enfim... era isso :D .. lembrando que pode haver questionamentos também.. E pelo que vi do modelo era isso..

[willian firmino]

Opa, dicas validas, já estou alterando aqui. No caso do Recursos Humanos é que cada atividade possui um coordenador e cada atividade também possui varias pessoas envolvidas o coordenador de uma atividade pode não ser coordenador em outra e mesmo assim estar entre as pessoas envolvidas. Não sei se deu para entender. esse foi um jeito tosco por sinal que achei de resolver esta questão.

--

[Marlysson Silva]

Poderia ter um atributo coordenador/responsável na atividade .. juntamente com um ManyToMany para os Membros.. assim os membros poderiam se relacionar com várias atividades.. e se houvesse outra Atividade só mudar o valor do coordenador/responsável .. Aí daria colocar pessoas que foram somente membros em uma atividade como coordenador em outras..

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasi...@googlegroups.com.

[willian firmino]

Desculpe, o coordenador/responsável seria um atributo de que tipo? não entendi direito.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasil+unsubscribe@googlegroups.com.

[Marlysson Silva]

Você está usando a RecursosHumanos para especificar uma pessoa participante e a CoordenadorPauta para os coordenadores certo?

As pessoas seriam do tipo RecursosHumanos, tanto na lista dos participantes nas atividades ( através do ForeignKey ) , quando o atributo para determinar o coordenador/responsavel... Pois ele também é uma pessoa ( RecursosHumanos , como ta na tua app )