Produits Entr'ouvert » Passerelle

Dont l'objectif est ?

Le but est de remonter les demandes de signalement de propreté dans Kimoce.
L'API expose des réferentiels des categories, types et sous-types de signalement, ainsi que la liste des voies qui pourrait être utilisée dans le formulaire pour l'aide à la saisie de l'adresse.
Avec ces informations on crée une demande dans Kimoce.
L'authentification auprès de l'API se fait par login/mot de passe qui delivre un jeton utilisé en authentification "Bearer": https://github.com/lexik/LexikJWTAuthenticationBundle/blob/master/Resources/doc/index.md#usage

Après le traitement et la cloture de la demande Kimoce viendra notifier wcs de l'avancement via un appel à trigger.

Code écrit pendant le 2 jours de sprint, testé avec l'API dévéloppée par dessus de Kimoce.

Pose self.check_status plutôt au début du modèle qu'au milieu des endpoint normaux (genre juste après get_token). Mais surtout j'avoue ne pas comprendre comment il va marcher : le get sur les catégories nécessite un token. À mon avis tu devrais limiter le check_status à l'obtention du token.

J'ai cru que self.request permettait de faire n'importe quelle requête, mais non, c'est juste pour attraper certaines listes et donc je l'appelerais plutôt self.get_list ou self.referential

Détail, mais ça serait bien de documenter l'affaire : picture1 et picture2, quels content_type sont possibles ? Aussi, on aura à utiliser cela dans wcs (on n'y a pas de possibilité d'envoyer du base64 uniquement), le serialiseur de fichiers envoie plutôt un dictionnaire avec filename/content_type/base64.

Pour les listes, tu pourrais implémenter ?q et ?id afin de rendre l'autocomplétion directement fonctionnelle.

Sur la création d'une demande, tu devrais renvoyer aussi le contenu de la réponse (en retirant ou réduisant quand même pictures parce que ça va bouffer de la place). Ca permettra de simplifier le support, de voir ce que le Kimoce a répondu.

Dans les tests, tu pourrais réduire la taille des exemples :) Mais aussi supprimer des trucs comme "adrien.millot@smile.fr" parce que bon.

Voili voilà.

Aussi, comme a dit Frédéric, utiliser le six de Django (si le urljoin de Django ne fait pas l'affaire, d'ailleurs ?). Et virer le import six qui ne sert à rien dans les tests.

Serghei Mihai a écrit :

L'api en face attend des photos, encodées en base64, sans content-type, sans nom car elle convertit le contenu en JPG et nomme les fichiers de son côté, d'après ses règles.

Mais en fait je me demande comment tu vas envoyer du base64 là dedans...?

Sur la création d'une demande, tu devrais renvoyer aussi le contenu de la réponse (en retirant ou réduisant quand même pictures parce que ça va bouffer de la place). Ca permettra de simplifier le support, de voir ce que le Kimoce a répondu.

Ok, mais en fait en retour le WS renvoie les noms des images créées, qui ne nous sert pas, et non leur contenu.

Impec.

J'avais raté le passerelle/utils/http_authenticators.py : en faire un premier patch séparé stp.

Aussi, un truc, le response.ok c'est assez large comme vérification, ça répond aussi ok pour un 302 par exemple. Faudrait pas plutôt tester que c'est un 2xx voire même 200 ?

Serghei Mihai a écrit :

Thomas Noël a écrit :

Mais en fait je me demande comment tu vas envoyer du base64 là dedans...?

Dans l'appel WS par wcs on fait comme d'habitude: form_var_fichier_raw qui sera sérialisé en dico avec filename, content et content-type. Et le connecteur ne prend que le content.

Rah, my bad, je viens de mieux relire et voir le « post_data[param_name]['content'] ». Je pensais qu'on pouvait décrire le truc dans le schéma JSON ?

Si on peut pas, il faut renforcer un peu le check, parce que ça va facilement plantouiller :

if post_data.get(param_name) and isinstance(post_data['param_name'], dict) and post_data['param_name'].get('content'):
    payload['pictures'].append({'content': post_data[param_name]['content']})

Aussi, un truc, le response.ok c'est assez large comme vérification, ça répond aussi ok pour un 302 par exemple. Faudrait pas plutôt tester que c'est un 2xx voire même 200 ?

Lors de la création d'une demande l'API en face renvoie une HTTP 201. Pas de 302 rencontrée lors des tests.

Donc c'est bien status_code // 100 == 2 qu'il faut tester (ie les 3xx sont un échec). Mais bon c'est un détail.

Désolé de relire mal, encore un truc que je trouve un peu dommage : on devrait remonter tout ce qui vient de leur référentiels et juste ajouter id/text. Par exemple sur les catégories, on reçoit :

    {"@id": "/api/categories/70",
     "id": 70,
     "label": "Table surface",
     "reference": "TBS" 
    },

On va prendre ici l'info "reference" qui ne sera pas remontée. Et si un jour Kimoce ajoute des choses, on ne les remontera pas non plus.

Selon moi, on devrait remonter un truc avec juste l'ajout de "text" :

    {
     "@id": "/api/categories/70",
     "id": 70,
     "label": "Table surface",
     "text": "Table surface",
     "reference": "TBS" 
    },

• s'il y a déjà un id, ne pas y toucher ; sinon l'ajouter avec la valeur de @id
• s'il y a déjà un text, ne pas y toucher, sinon l'ajouter avec la valeur de "label" ou de "id" (du premier qui existe)

Je ferais ça sur get_referential et sur streets, surtout dans l'idée que tout cela pourrait grandir chez Kimoce (et le connecteur grandira avec, tranquille)

A relire streets, je comprends pas bien le passage :

        if 'id' in kwargs:
            params['streetAddress'] = kwargs['id']
        if 'q' in kwargs:
            params['streetAddress'] = kwargs['q']

et je pense qu'il y a un bogue au niveau de la ligne 193, la variable "q" n'existe pas (il faut refaire la même requete qu'au dessus, juste renouveller le token)