ZEP-30 : Elaboration de l'API des forums

Je pense au contraire qu'il n'y a aucune raison valable de le faire. Dans les forums, il y a deux catégories, peut-être prochainement une troisième, et elles ne sont qu'une commodité visuelle pour l'organisation des forums-unités. D'ailleurs, on ne peut y accéder que de manière indirecte en remontant le fil d'Ariane.

Dans les tutos et articles, elles sont le principal moyen de classement du contenu, et correspondent plutôt dans leur utilisation aux forums-unités, les catégories de forum correspondant aux « grands domaines » dans lesquels les catégories sont rangées, et qui ne sont pas accessibles directement. Le fait que ces deux outils s'appellent « catégories » est un hasard, car ils ne sont pas de même nature.

Si vraiment tu veux fusionner / rapprocher les classes des différents modules, il faut fusionner les catégories de forums avec les grands domaines des tutos/articles, et les forums-unités avec les catégories de tutos/articles. Aucune idée de si ce serait faisable techniquement, dans l'état actuel du code, mais c'est la seule solution qui ait du sens. Et il y aurait très certainement un intérêt à rapprocher les futurs tags des tutos/articles prévus par la ZEP-25 de ceux des contenus, voire à n'en faire qu'un seul « objet ».

D'ailleurs, le fonctionnement des catégories de forums pourrait largement se rapprocher de celui des tags. Ces derniers sont une « caractéristique » des sujets, et sont créés / supprimés / renommés en fonction des modifications apportées aux titres des sujets. Les catégories pourraient être créées / supprimées / renommées par le biais d'un paramètre « catégorie » des forums (accessible dans l'API par la fonction de création / modif / suppression de forum).

Le seul point qui ne serait pas géré avec un tel système, c'est l'ordre d'affichage des catégories : peut-être peut-on considérer que ce choix est laissé à l'appréciation du client de l'API ?

D'accord d'accord je comprend, mais catégorie n'est pas une ressource de premier niveau du coup… je veux dire quand ont dit catégories cela n'a de sens que si on sais quel est le contexte.

Pour moi la meilleure solution serai des urls du type /forum/categories.

Je pense au contraire qu'il n'y a aucune raison valable de le faire. Dans les forums, il y a deux catégories, peut-être prochainement une troisième, et elles ne sont qu'une commodité visuelle pour l'organisation des forums-unités. D'ailleurs, on ne peut y accéder que de manière indirecte en remontant le fil d'Ariane.

Je ne peux pas être d'accord avec ça. Les catégories des forums sont des catégories réelles, c'est la navigation du site qui donne l'impression qu'elles ne sont pas importantes. Je disais dans un autre sujet qu'il ne faut pas confondre site et api. Le site répond à un besoin différent de l'API. Là où le site tente d'offrir une navigation la plus adéquate possible pour les utilisateurs, l'API fournit toutes les données. Elles ne se soucient pas de la navigation (pas au sens ergonomie). Il y a déjà une simplification en dissociant, dans les URLs, les catégories des forums, cela semble bien assez pour indiquer que les catégories ne sont pas forcément une chose indispensable pour les forums. Bien que cela reste discutable, cette information peut être indispensable pour une application tierce.

Si vraiment tu veux fusionner / rapprocher les classes des différents modules, il faut fusionner les catégories de forums avec les grands domaines des tutos/articles, et les forums-unités avec les catégories de tutos/articles.

Ce n'était pas une bonne idée de parler de la technique mais ce n'est pas ce que je proposais. Juste une base commune.

D'ailleurs, le fonctionnement des catégories de forums pourrait largement se rapprocher de celui des tags.

Je suis désolé mais j'ai failli arrêté de lire ton message à cette ligne. Il n'y a juste aucun rapport entre les catégories des forums et les tags (pour n'importe quel type que tu veux).

Le seul point qui ne serait pas géré avec un tel système, c'est l'ordre d'affichage des catégories : peut-être peut-on considérer que ce choix est laissé à l'appréciation du client de l'API ?

Je ne vois aucun problème et n'est pas le sujet actuellement.

@La source : Je ne vais pas me répéter. Nos avis divergent. Je vais attendre d'autres avis.

Personne n'a d'autre avis ?

Comme quoi, la question n'est peut-être pas si intéressante que ça.

Faut croire… ce qui est bien dommage je trouve, pas tellement que ce point soie tellement primordial mais c'est un peu bête de demander à la communauté d'élaborer les prochaines fonctionnalité de ZdS mais finalement bah sa ne tien finalement qu'à l'auteur de la ZEP avec quelques remarques d'autres membres (sauf quelques exceptions).

Moi quand j'avais découvert ce principe de ZEP j'avais imaginer quelque chose de… différent

La source, ce qui se passe c'est qu'au final c'est le développeur "leader" de la ZEP qui va s'occuper du dev'. Mais cette dernière sera validée par d'autres dev' avant de dire "ok c'est raisonnable partons sur ca".

Il faut aussi voir que de temps en temps personne n'a la bonne réponse (ou alors on pense l'avoir et se tromper, ou on pense l'avoir (à raison) mais sans réussir à faire passer les bons arguments au bon moment (ce qui est dommage mais c'est la vie).

Cependant tout avis est bon à prendre et à le mérite de soulever des réflexions, et c'est aussi en ca que les ZEP servent. Maintenant je suis désolé que tu te sentes incompris dans le cheminent de cette question. (Mais j’espère que tu admettras qu'à un moment qqun doit trancher dans les décisions pour avancer). Je suis sur que si tu as des remarques/questions précises sur un choix Andr0 se fera un plaisir de t'expliquer le choix final dans un MP.

Comme nous n'arrivons pas à statuer sur les catégories et qu'en fin de compte, on s'en cogne des catégories dans les forums, je propose de ne pas les inclure dans cette première version de l'API des forums, tout simplement. Cela donnerait la mise à jour suivante de la ZEP.

Routes

* : Il faut être authentifié

** : Il faut appartenir au staff

Autres

Karma

1
2
3
4
5
6
7

{
  "karma": {
    "like": 42,
    "dislike": 0,
    "status": "liked" # status: none | liked
  }
}

Permissions

Toutes les ressources retournent l'objet un objet permissions pour spécifier si le staff, un utilisateur connecté ou un auteur peut ou non édité la ressource demandée.

1
2
3
4
5
6
7
8

{
  ...
  "permissions": {
    "staff": true,
    "auteur": true,
    "membre": false
  }
}

micro-remarque (mais vraiment toute micro micro) : c'est plus lisible si tu mets l'URL dans la colonne qui jouxte la méthode HTTP.

GET /api/1/forums/ : liste les forums

sinon bon boulot

Je pense que ça tombe sous le sens mais pour "Like un message", "Retire le like sur un message" , "Dislike un message", "Retire le dislike sur un message" et "Alerte un message", il faut être connecté.

Mon dernier message semble faire l'unanimité. J'ai modifié le premier message de la ZEP. Je pense que nous pouvons passer à la validation de cette ZEP.

Pour information, j'ai fais une PR pour afficher les permissions dans l'API des membres et des MPs. Plus d'info sur les différents attributs sur la PR en question : https://github.com/zestedesavoir/zds-site/pull/3264

Sinon, je propose qu'on passe la ZEP en accepté. Ca fait depuis octobre que plus personne n'a quelque chose à dire sur les spécifications de l'API des forums.

Que toutes les personnes qui sont pour passer en "validé" plussoient le poste d'Andro

J’ai juste une question. Dans les deux cas suivants

GET /api/sujets Liste tous les sujets d’un forum
POST /api/sujets Crée un sujet*

comment spécifie-t-on le forum dans lequel on se place ? En particulier pour le POST, comment est-on censé dire dans quel forum doit être créé le nouveau sujet ?

Je pense que ça sera dans l'objet json qui sera envoyé dans le post. Pour plus de détail, il faudra attendre que l'API soit développée pour que swagger nous donne la doc complète.

C'est exactement ça, l'information est dans l'objet "sujet" et est renseigné aussi dans l'objet lors de sa création.

Pourquoi ne précise-t-on pas le sujet dans l'objet au lieu de dans l'url pour le PUT /api/sujets/:sujet ?

Je ne comprends pas bien la question.

http://programmers.stackexchange.com/questions/263925/to-include-a-resource-id-in-the-payload-or-to-derive-from-uri

L'idée de base c'est en effet que les routes soient "symétriques" entre lire/écrire.

Un exemple parmi 1000, tu veux savoir qui (quelle adresse IP) a modifié le sujet tartempion rien qu'en regardant les logs http.

Merci.

les devs à dimension non entière valident.