Autre #17175
Mis à jour par Frédéric Péters il y a presque 7 ans
Je prends ce ticket à l'occasion de commentaires récents de ma part, comme quoi je n'étais pas à l'aise avec le mode "json-api", en preuve plutôt simple, d'un "git grep", j'ai l'impression que les connecteurs qui utilisent @endpoint sans "json-api", c'est uniquement ceux que j'ai développé moi :/
En guise d'inventaire/documentation, 'json-api', ça fait :
* la mise de la réponse sous une clé 'data'
** sauf si wrap_response=False est passé
** sauf si la réponse est de type HttpResponse, alors c'est envoyé brut
* l'ajout d'une clé 'err' à 0 de manière automatique
* l'attrapage des exceptions (sauf si ?raise=1 est passé dans l'URL)
** si l'exception contient un attribut err_code, il est utilisé dans la clé 'err'.
** si l'exception contient un attribut http_status, il est utilisé pour la réponse.
** si c'est ObjectDoesNotExist ou Http404, c'est une 404 qui est produite.
** si c'est PermissionDenied, une 403
Maintenant la discussion. Je me demande dans quel mesure, à l'exception du premier point, tout pourrait également se faire quand on ne précise rien; c'est à dire que sans rien préciser, ça reviendrait à json-api + wrap_response=False.
De là, retirer de @endpoint les arguments serializer_type et wrap_response, ce qui simplifie tout à fait la documentation développeur, avec comme seule obligation la modification des connecteurs "json-api" actuels pour qu'ils modifient leur réponse pour la mettre dans une clé "data".
Question code, ça pourrait commencer sans rien changer (d'autre que la clé "data") mais à terme je serais tenté par dégager passerelle/utils/jsonresponse.py, dont je n'aime pas le code (mais 80% ça doit être la chaine de doctest).
En guise d'inventaire/documentation, 'json-api', ça fait :
* la mise de la réponse sous une clé 'data'
** sauf si wrap_response=False est passé
** sauf si la réponse est de type HttpResponse, alors c'est envoyé brut
* l'ajout d'une clé 'err' à 0 de manière automatique
* l'attrapage des exceptions (sauf si ?raise=1 est passé dans l'URL)
** si l'exception contient un attribut err_code, il est utilisé dans la clé 'err'.
** si l'exception contient un attribut http_status, il est utilisé pour la réponse.
** si c'est ObjectDoesNotExist ou Http404, c'est une 404 qui est produite.
** si c'est PermissionDenied, une 403
Maintenant la discussion. Je me demande dans quel mesure, à l'exception du premier point, tout pourrait également se faire quand on ne précise rien; c'est à dire que sans rien préciser, ça reviendrait à json-api + wrap_response=False.
De là, retirer de @endpoint les arguments serializer_type et wrap_response, ce qui simplifie tout à fait la documentation développeur, avec comme seule obligation la modification des connecteurs "json-api" actuels pour qu'ils modifient leur réponse pour la mettre dans une clé "data".
Question code, ça pourrait commencer sans rien changer (d'autre que la clé "data") mais à terme je serais tenté par dégager passerelle/utils/jsonresponse.py, dont je n'aime pas le code (mais 80% ça doit être la chaine de doctest).