1:55 p.m.
Super. Par la même occasion, ce serait super de faire les tests en
même temps, voire avant. Je pense à ça comme tests (en utilisant
Behat) :
https://github.com/nikrou/phyxo/blob/master/features/api/pwg.categories.g...
https://github.com/nikrou/phyxo/blob/master/features/api/pwg.images.addSi...
Yup, très bonne idée. admin/services.php ne demande qu'à être complété :)
Concernant le formalisme JSON utilisé, il y a des conventions quelque part ?
--
Bruno
2:01 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Yup, très bonne idée. admin/services.php ne demande qu'à être
complété :)
Concernant le formalisme JSON utilisé, il y a des conventions quelque part ?
Je ne suis peut-être pas clair : pour dotAjax, j'avais choisi quelques
messages arbitraires en JSON, du genre :
* service non trouvé : {'status':'failed','message':'function
does not exist'}
* succès de la requête : {'status':'ok', 'data':{(réponse du
service)} }
--
Bruno
2:28 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Le 9 août 2013 14:01, Dsls <dsls(a)morefnu.org> a écrit :
> Yup, très bonne idée. admin/services.php ne demande qu'à être
complété :)
>
> Concernant le formalisme JSON utilisé, il y a des conventions quelque part ?
Je ne suis peut-être pas clair : pour dotAjax, j'avais choisi quelques
messages arbitraires en JSON, du genre :
* service non trouvé : {'status':'failed','message':'function
does not exist'}
* succès de la requête : {'status':'ok', 'data':{(réponse du
service)} }
Oui ou mieux en se basant sur le code http : 200 ok, sinon 401, 403,
404, 500,...
2:41 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Oui ou mieux en se basant sur le code http : 200 ok, sinon 401, 403,
404, 500,...
Exact. Dans ce cas on se contente de balancer le code d'erreur
http,
ou on peut mettre un message aussi ? (et dans ce cas, avec quel
formalisme)
C'est une question intéressée, j'ignore s'il y a un état de l'art sur
le sujet, et s'il faut envisager des "best practices" sur la
structuration des réponses à renvoyer.
2:49 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Le 9 août 2013 14:41, Dsls <dsls(a)morefnu.org> a écrit :
> Oui ou mieux en se basant sur le code http : 200 ok, sinon 401,
403,
> 404, 500,...
Exact. Dans ce cas on se contente de balancer le code d'erreur http,
ou on peut mettre un message aussi ? (et dans ce cas, avec quel
formalisme)
C'est une question intéressée, j'ignore s'il y a un état de l'art sur
le sujet, et s'il faut envisager des "best practices" sur la
structuration des réponses à renvoyer.
C'est une question intéressée et intéressante. Je pense qu'on peut
mettre les deux (cela permet d'avoir des messages traduits pour
l'utilisateur de l'API) mais je dois avouer que je ne sais pas quelles
sont les bonnes pratiques.
3:06 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Le 9 août 2013 13:49, Nicolas <nikrou77(a)gmail.com> a écrit :
Le 9 août 2013 14:41, Dsls <dsls(a)morefnu.org> a écrit :
>> Oui ou mieux en se basant sur le code http : 200 ok, sinon 401, 403,
>> 404, 500,...
> Exact. Dans ce cas on se contente de balancer le code d'erreur http,
> ou on peut mettre un message aussi ? (et dans ce cas, avec quel
> formalisme)
>
> C'est une question intéressée, j'ignore s'il y a un état de l'art
sur
> le sujet, et s'il faut envisager des "best practices" sur la
> structuration des réponses à renvoyer.
C'est une question intéressée et intéressante. Je pense qu'on peut
mettre les deux (cela permet d'avoir des messages traduits pour
l'utilisateur de l'API) mais je dois avouer que je ne sais pas quelles
sont les bonnes pratiques.
Pour avoir fréquenté pas mal d'API, la meilleure réponse est d'avoir
toujours la même enveloppe que ce soit pour une réponse ok ou une erreur.
Exemple: {status: 0, data: {}, errors: []}
Mettre ensuite le "status" à 1 ou 0, OK ou KO enfin peut importe, quelque
chose qui spécifie si la réponse est une erreur ou non. Les données de
retour vont dans "data" et le(s) message(s) d'erreur dans
"errors".
Pourquoi ne pas utiliser les codes HTTP directement? Parce qu'avec ce
format, le client peut déterminer si il y a un problème sur le serveur
(code HTTP != 200) ou sur l'API (sa requête / ses paramètres / etc...) et
ainsi avoir une gestion plus fine du message d'erreur à afficher à
l'utilisateur.
--
Thomas Bouron
3:14 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Pourquoi ne pas utiliser les codes HTTP directement? Parce
qu'avec ce
format, le client peut déterminer si il y a un problème sur le serveur
(code HTTP != 200) ou sur l'API (sa requête / ses paramètres / etc...) et
ainsi avoir une gestion plus fine du message d'erreur à afficher à
l'utilisateur.
D'un autre coté, Nicolas a raison, en REST on cause http, donc si on
trouve pas quelque chose, on renvoie un 404. En revanche je ne sais
pas si c'est facilement gérable via jquery & cie. Si c'est bien géré,
ça veut dire que success') n'est pas appelé, et ça évite d'avoir un
traitement spécifique en js, ou plutôt ça le déporte proprement vers
le fail().
--
Bruno
10:20 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Le 09/08/2013 15:14, Dsls a écrit :
> Pourquoi ne pas utiliser les codes HTTP directement? Parce
qu'avec ce
> format, le client peut déterminer si il y a un problème sur le serveur
> (code HTTP != 200) ou sur l'API (sa requête / ses paramètres / etc...) et
> ainsi avoir une gestion plus fine du message d'erreur à afficher à
> l'utilisateur.
D'un autre coté, Nicolas a raison, en REST on cause http, donc si on
trouve pas quelque chose, on renvoie un 404. En revanche je ne sais
pas si c'est facilement gérable via jquery & cie. Si c'est bien géré,
ça veut dire que success') n'est pas appelé, et ça évite d'avoir un
traitement spécifique en js, ou plutôt ça le déporte proprement vers
le fail().
--
Bruno
Si vraiment on se lance dans une API JSON je suis votre home, je l'ai
déjà fait et déjà perdu, gloups.
Dans l'idée il faut séparer l'API REST standard de l'API JSON, j'avais
fait donc un clone dans services_json.php
Et pour info la réponse de Thomas Bouron sur le format/structure de
réponse est parfaitement juste ! :-)
10:26 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Re,
> Bruno
Si vraiment on se lance dans une API JSON je suis votre home, je l'ai
déjà fait et déjà perdu, gloups.
Dans l'idée il faut séparer l'API REST standard de l'API JSON, j'avais
fait donc un clone dans services_json.php
Et pour info la réponse de Thomas Bouron sur le format/structure de
réponse est parfaitement juste ! :-)
Super. Demain j'essaie de faire la mise en place des tests et on peut y aller !
Je commit ça dans default ?
10:43 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Euh… dites les gens, je vous vois chaud bouillant, mais la branche default
c'est la future 2.6 et la patronne de ça c'est Ève, faudrait peut-être lui
en toucher deux mots avant de commiter, non ?
Le 9 août 2013 22:26, Nicolas <nikrou77(a)gmail.com> a écrit :
Re,
>> Bruno
> Si vraiment on se lance dans une API JSON je suis votre home, je l'ai
> déjà fait et déjà perdu, gloups.
> Dans l'idée il faut séparer l'API REST standard de l'API JSON,
j'avais
> fait donc un clone dans services_json.php
> Et pour info la réponse de Thomas Bouron sur le format/structure de
> réponse est parfaitement juste ! :-)
Super. Demain j'essaie de faire la mise en place des tests et on peut y
aller !
Je commit ça dans default ?
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
10:47 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
De plus je ne pense pas que ce sera prêt pour la 2.6 il y a du boulot
dessus quand même...
Le 09/08/2013 22:43, Franck Paul a écrit :
Euh… dites les gens, je vous vois chaud bouillant, mais la branche
default
c'est la future 2.6 et la patronne de ça c'est Ève, faudrait peut-être lui
en toucher deux mots avant de commiter, non ?
11:07 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Le 9 août 2013 22:43, Franck Paul <carnet.franck.paul(a)gmail.com> a écrit :
Euh… dites les gens, je vous vois chaud bouillant, mais la branche
default
c'est la future 2.6 et la patronne de ça c'est Ève, faudrait peut-être lui
en toucher deux mots avant de commiter, non ?
Du coup je commite ça dans une nouvelle branche ?
11:10 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Le 9 août 2013 23:07, Nicolas <nikrou77(a)gmail.com> a écrit :
Du coup je commite ça dans une nouvelle branche ?
Et un PR où piochera le chef de branche quand il en aura besoin, ce
serait idiot ?
--
Anne / Kozlika
11:11 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Le 9 août 2013 23:10, Kozlika <kozlika(a)gmail.com> a écrit :
Le 9 août 2013 23:07, Nicolas <nikrou77(a)gmail.com> a écrit :
>
> Du coup je commite ça dans une nouvelle branche ?
Et un PR où piochera le chef de branche quand il en aura besoin, ce
serait idiot ?
Il va y avoir beaucoup de commit. Bon je vais jouer chez moi sur ma branche. :-)
11:20 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Hi hi, quel sens de la diplomatie.
Donc, ça serait idiot. J'ai compris, va ;-)
Le 9 août 2013 23:11, Nicolas <nikrou77(a)gmail.com> a écrit :
Le 9 août 2013 23:10, Kozlika <kozlika(a)gmail.com> a écrit :
> Le 9 août 2013 23:07, Nicolas <nikrou77(a)gmail.com> a écrit :
>>
>> Du coup je commite ça dans une nouvelle branche ?
>
> Et un PR où piochera le chef de branche quand il en aura besoin, ce
> serait idiot ?
Il va y avoir beaucoup de commit. Bon je vais jouer chez moi sur ma branche. :-)
--
Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev
--
Anne / Kozlika
6:45 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Je comprends pas trop votre histoire là.
Une grosse feature avec plein de commits => développement sur un repo
séparé, sur une branche séparée
puis PR lorsque c'est prêt
Pourquoi faire autrement ?
2013/8/9 Kozlika <kozlika(a)gmail.com>
Hi hi, quel sens de la diplomatie.
Donc, ça serait idiot. J'ai compris, va ;-)
Le 9 août 2013 23:11, Nicolas <nikrou77(a)gmail.com> a écrit :
> Le 9 août 2013 23:10, Kozlika <kozlika(a)gmail.com> a écrit :
>> Le 9 août 2013 23:07, Nicolas <nikrou77(a)gmail.com> a écrit :
>>>
>>> Du coup je commite ça dans une nouvelle branche ?
>>
>> Et un PR où piochera le chef de branche quand il en aura besoin, ce
>> serait idiot ?
>
> Il va y avoir beaucoup de commit. Bon je vais jouer chez moi sur ma
branche. :-)
> --
> Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Anne / Kozlika
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
6:55 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
Le 10 août 2013 18:45, Julien Wajsberg <felash(a)gmail.com> a écrit :
Je comprends pas trop votre histoire là.
Une grosse feature avec plein de commits => développement sur un repo
séparé, sur une branche séparée
puis PR lorsque c'est prêt
Pourquoi faire autrement ?
C'est ce que j'ai dit et proposé.
Avec piwigo on ne faisait pas exactement de la même manière. On
développait tout dans le tronc (master) et on tirait des branches
(code freezé) quand on décidait de sortir une nouvelle version.
Ici j'ai l'impression qu'on freeze, tire une branche dès que la
précédente a été faite. master contient déjà la future 2.6 alors que
ce pourrait être une 3.0 si on le décidait.
6:59 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
2013/8/10 Nicolas <nikrou77(a)gmail.com>
Le 10 août 2013 18:45, Julien Wajsberg <felash(a)gmail.com> a
écrit :
> Je comprends pas trop votre histoire là.
>
> Une grosse feature avec plein de commits => développement sur un repo
> séparé, sur une branche séparée
> puis PR lorsque c'est prêt
>
> Pourquoi faire autrement ?
C'est ce que j'ai dit et proposé.
Avec piwigo on ne faisait pas exactement de la même manière. On
développait tout dans le tronc (master) et on tirait des branches
(code freezé) quand on décidait de sortir une nouvelle version.
Ici j'ai l'impression qu'on freeze, tire une branche dès que la
précédente a été faite. master contient déjà la future 2.6 alors que
ce pourrait être une 3.0 si on le décidait.
Pour les features qui vont mettre du temps à faire, je suis assez réticent
à pousser sur le tronc. Sauf si chaque commit se tient individuellement.
Par ailleurs, faire des PR, ça permet aussi la relecture du code par les
pairs :)
7:20 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
> Avec piwigo on ne faisait pas exactement de la même manière. On
> développait tout dans le tronc (master) et on tirait des branches
> (code freezé) quand on décidait de sortir une nouvelle version.
> Ici j'ai l'impression qu'on freeze, tire une branche dès que la
> précédente a été faite. master contient déjà la future 2.6 alors que
> ce pourrait être une 3.0 si on le décidait.
>
Pour les features qui vont mettre du temps à faire, je suis assez réticent
à pousser sur le tronc. Sauf si chaque commit se tient individuellement.
Oui c'était la politique adopté. Chaque commit ne devait rien casser
sous peine de revert. Mais cela avait l'inconvénient de faire de plus
gros commit, pas forcément plus facile à suivre.
Mais il faut dire que c'est avec subversion qui n'a pas une gestion
légendaire des branches !!
Par ailleurs, faire des PR, ça permet aussi la relecture du code par les
pairs :)
Et oui.
6:44 p.m.
New subject: API REST [was: Re: [ergo] [default]Admin responsive]
2013/8/9 Thomas Bouron <tbouron(a)gmail.com>
Pourquoi ne pas utiliser les codes HTTP directement? Parce qu'avec ce
format, le client peut déterminer si il y a un problème sur le serveur
(code HTTP != 200) ou sur l'API (sa requête / ses paramètres / etc...) et
ainsi avoir une gestion plus fine du message d'erreur à afficher à
l'utilisateur.
Note qu'avec les codes HTTP tu peux differencier les problèmes aussi:
* 5xx => problème lié au serveur, que le client ne peut pas corriger
* 4xx => problème lié au client (ex le plus connu 404) que le client peut
généralement corriger
Donc généralement on va quand même choisir un code HTTP qui va bien. Même
si avoir un status peut-être plus précis dans le json est à mon avis aussi
une bonne idée.
3935
days inactive
3936
days old
19 comments
7 participants
participants (7)
-
Denis Jean-Christian -
Dsls -
Franck Paul -
Julien Wajsberg -
Kozlika -
Nicolas -
Thomas Bouron