Un développeur front-end doit-il jamais spécifier le format JSON pour les développeurs back-end?


17

Je joue le rôle de front-end dans un projet. Dois-je spécifier à mes coéquipiers principaux le format exact de JSON que leur PHP renvoie à mon JavaScript?

Par exemple, dois-je leur dire qu'ils doivent utiliser un format similaire à celui décrit ici:

Façon appropriée de structurer JSON pour la consommation frontale

Ou devrais-je garder mon rôle aussi stérile que possible et décrire simplement en mots les entrées et sorties dont j'ai besoin à partir de leur interface principale? (Bien sûr, si cela se produit, il pourrait être plus difficile de ma part de gérer leurs différents formats de structure de données)


10
Je pouvais voir qu'il était logique pour eux de faire la première proposition sur la base d'une contribution générale. Mais cela ne signifie pas que la conversation s'arrête à la première proposition.
Doug T.

Ça a du sens!
LazerSharks

4
Quelqu'un doit spécifier le format exact des données contenues dans le JSON. Autant être toi. Vraiment, ce devrait être celui qui a le plus d'expérience dans la création de spécifications.
gnasher729

2
@ gnasher729: ou si le format est si simple que vous êtes sûr que les deux parties sont plus que qualifiées pour le spécifier, celui qui écrit le premier code qui a besoin de le connaître doit le spécifier. Cela peut également être considéré comme une récompense pour celui qui est le plus rapide pour commencer ses tests ;-) En général, on pourrait dire que la personne qui le fait ne devrait pas toujours être la personne ayant le plus d'expérience, il est souvent préférable d'utiliser la personne avec le moins l'expérience qui est suffisante pour la tâche, mais c'est une question de développement de la personne.
Steve Jessop

Réponses:


42

Il s'agit d'une conversation que vous devriez avoir ensemble, en discutant des exigences, des avantages et des inconvénients des différents formats.

Si un côté ou l'autre dicte ce qui se passe, vous allez vous retrouver avec un mauvais logiciel et une équipe malheureuse.


1
Ça a du sens! Je me demandais ce qui se passe vraiment / habituellement dans le monde du développement.
LazerSharks

5
Droite. Vous travaillez ensemble dessus. Si c'est quelque chose d'un peu compliqué, vous trouverez idéalement un format commun pris en charge par les bibliothèques aux deux extrémités, pour rendre le développement plus facile / plus rapide.
AE

9

Vous devriez certainement contribuer à la façon dont le format et la structure du JSON devraient ressembler. Je vois plus que souvent que les ingénieurs front-end, les consommateurs d'API, sont ceux qui savent comment la structure de données devrait être.

Vous êtes celui qui va utiliser les données, les formater, les parcourir et les utiliser. Vous devriez avoir une opinion sur la façon dont vous voulez qu'il soit livré.


3

Bienvenue dans le monde merveilleux du développement de middleware. L'élaboration d'un protocole peut demander beaucoup de travail et de débats, et personne ne devrait jamais voir les résultats.

Si vous faites partie d'une petite équipe, évitez un dictateur: rencontrez rapidement tout le monde pour élaborer le protocole.

Les équipes de taille moyenne peuvent souhaiter avoir des représentants qui élaborent le protocole.

Les grandes équipes et / ou les équipes avec une organisation complexe doivent avoir des personnes middleware dédiées pour contrôler le protocole.

Dans tous les cas, documentez! Quelles sont les conditions préalables, quelles sont les post-conditions, quels sont les champs obligatoires, quels sont les champs facultatifs, quels sont les effets secondaires, quelles erreurs sont renvoyées… Gardez le document vivant, lorsque de nouvelles conditions, types d'erreurs ou effets secondaires sont trouvés , puis ils sont ajoutés au document.

Je recommanderais également des tests unitaires côté client et serveur et des tests système pour assurer la conformité au document.

Cela peut sembler beaucoup de travail, mais les faux pas mineurs ici peuvent être très coûteux et longs.


Ah, heureux d'apprendre qu'il y a tout un monde dédié à cet aspect. Je pensais que cet aspect semble être l'endroit où le caoutchouc rencontre vraiment la route en termes de division entre le front-end et le back-end.
LazerSharks

1

Je voudrais simplement demander pourquoi pas? Lorsque nous parlons d'un projet, nous parlons également de l'équipe qui y travaille et il est attendu et devrait être le bienvenu pour entendre une opinion sur les fonctionnalités et la structure utilisées. En tant que développeur, je crois personnellement et apprécie les contributions des coéquipiers.

Vous savez qu'il y a un dicton "si vous voulez aller vite, allez seul. Si vous voulez aller loin, allez ensemble".

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.