ZEP-23 : Elaboration de l'API des MPs

a marqué ce sujet comme résolu.

J'adore tes interventions Javier. ^^

Je comprends un peu mieux les choses. Du coup, j'ai fais un petit test pour voir si c'était possible puisque, je l'avoue sans trop comprendre, j'avais fais le nécessaire pour que ça soit possible. Donc, faire ce genre de requête :

1
curl -i -X PUT -H "Content-Type: application/json" -H "Authorization: Bearer Token" http://localhost:8000/api/mps/2/ -d @edit-mp.json

Traite correctement la requête :

1
2
3
4
5
6
7
8
HTTP/1.0 200 OK
Date: Fri, 15 May 2015 13:41:57 GMT
Server: WSGIServer/0.1 Python/2.7.9
Vary: Accept
Content-Type: application/json
Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS

{"id":2,"title":"la mère à boire","subtitle":"la bouteille à la mère","participants":[2,3]}

La bonne nouvelle : C'est que l'API permet de gérer ce Content-Type (et devrait l'être pour l'XML aussi) même pour les méthodes POST et PUT.

La mauvaise, c'est qu'effectivement, ça ne supporte pas l'implémentation actuelle pour ajouter des participants.

T'as mis quoi dans le contenu de ta requête JSON du coup ?

1
participants:[2,3]

??

Si c'est ça je pense que ça suffit hein :)

Faut juste gérer proprement un certain nombre de cas chiants (tableau vide, pas de noeud "participants", …) mais ça devrait pas être la mort.

+0 -0

Bien le bonjour à tous,

C'est une triste nouvelle que je viens apporter aujourd'hui : l'API des MPs ne sera pas incluse dans la prochaine release, la v15.5.1.

Alors pourquoi ? Non, ce n'est pas parce que nous avons trouvé beaucoup de bugs ou qu'elle ne satisfait pas les testeurs. Elle ne sera pas incluse pour 3 raisons :

  1. Il n'est pas possible de la tester sur le serveur en bêta avec une base de données iso prod (chose qui a son importance, ça sera expliqué dans les points suivants). Nous avons un conflit sur l'en-tête d'authentification entre l'authentification de l'API et l'authentification auprès du serveur avec le htaccess. Si vous avez des compétences là dedans, nous sommes ouvert à toutes les solutions.
  2. Pour des raisons historiques, ZdS cohabite avec 2 tables pour les utilisateurs : Profile créé par nous et User créé par Django. Ensemble, ces 2 tables forment un seul utilisateur. Cependant, à partir de l'utilisateur 757 précisément, une incohérence dans les identifiants de ces 2 tables a été notée et avec ça, son lot de problèmes. Alors pourquoi ça impact l'API ? Parce que nous fournissons des identifiants de la table Profile dans l'API des membres mais que toutes les tables sont liées à la table User. Donc si vous avez un identifiant supérieur à 757, il faut l'incrémenter pour l'utiliser. Pour plus d'information technique sur le sujet, je vous invite à consulter son issue.
  3. Tout ceci nous entraine dans une situation un peu délicate. La solution sur laquelle nous nous sommes arrêtée pour l'incohérence des identifiants demande des changements considérables dans le projet, qui va impacter tous les modèles actuels et demander une maintenance lourde lors de son application en prod. Hors, nous avons de grosses ZEP en cours dont la ZEP-12 sur le refactoring des tutos/articles ou la ZEP-30 avec une PR sur le refactoring complet du module des forums. Il faut donc que ces 2 contributions soient mergées avant de mettre en oeuvre notre solution. Chose qui pourrait prendre du temps puisque la ZEP-12 n'est pas encore du tout à l'étape de PR sur le dépôt principal.

Qu'est ce que cela implique : L'API des MPs sera mergée en production mais elle sera désactivée ; Malheureusement, le freeze du développement de l'API jusqu'à la mise en oeuvre de la solution.

Voilà pour la situation, toutes mes excuses pour ce désagréablement et j'espère que tout se débloquera très vite.

Donc si vous avez un identifiant supérieur à 757, il faut l'incrémenter pour l'utiliser.

Pour être exact, à chaque fois que vous avez un Profile il faudrait récupérer l'ID de l'utilisateur correspondant. Et comme ce sont des IDs techniques, il n'y a aucune garantie qu'ils soient les mêmes : ça n'a été que pure coïncidence jusqu'au 757.

Aïe, c'est dommage mais c'est le choix de la raison.

Tant que le boulot effectué n'est pas perdu c'est pas bien grave (et même si c'était le cas, ça ne serait pas dramatique non plus).

Merci pour l'info en tout cas, et bon courage pour le rafactor. C'est jamais sympa à faire mais quand c'est fini en général on se sent soulagé !

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte