Should a front-end developer ever specify JSON format for back-end developers?

Question

I am taking the front-end role in a project. Should I be specifying for my back-end teammates the exact format of JSON that their PHP returns to my JavaScript?

For example, should I be telling them they should use a format similar to one described here:

Proper way to structure JSON for front-end consumption

Or should I keep my role as sterile as possible, and simply describe in words the inputs and outputs I need from their back-end interface? (Of course, if this happens it might be more difficult on my part to handle their different data structure formats)

• Doug T.: I could see it making sense for them to make the first proposal based on general input. But that doesn't mean the conversation stops at the first proposal.
• LazerSharks: That makes sense!
• gnasher729: Someone must specify the exact format of the data contained in the JSON. Might as well be you. Really, it should be whoever has the most experience creating specs.
• Steve Jessop: @gnasher729: or if the format is so simple that you're confident both parties are more than qualified to specify it, whoever writes the first code that needs to know it should spec it. This can also be considered a reward to whoever is quickest to get started on their tests ;-) In general one might say that the person to do it should not always be the person with most experience, often it's better to use the person with least experience who is sufficient to the task, but that's a matter of person-development.

Answer 1

This is a conversation you should be having together, discussing the requirements and pros and cons of different formats.

If one side or the other is dictating what happens, you're going to end up with bad software and an unhappy team.

• LazerSharks: That makes sense! Was wondering what really/usually happens out there in the development world.
• A E: Right. You work together on it. If it's something a bit complicated then ideally you find a common format supported by libraries at both ends, to make development easier / quicker.

Answer 2

You most definetly should contribute to how the format and structure of the JSON should look like. I see it more than often that the front-end engineers, the API consumers, is the ones knowing how the data-structure should be.

You are the one going to use the data, format it, loop through it and work with it. You should have an opinion on how you want it delivered.

Answer 3

Welcome to the wonderful world of middleware development. It can be a lot of hard work and debate to develop a protocol, and no one should ever see the results.

If you are on a small team, then avoid a dictator: have quick meetings with everyone to hammer out the protocol.

Medium sized teams may wish to have representatives that work out the protocol.

Large teams and/or teams with complex organization should have dedicated middleware people to control the protocol.

In all cases document! What are the preconditions, what are the post-conditions, what are required fields, what are optional fields, what are the side effects, what errors are returned... Keep the document living, when new conditions, error types, or side effects are found, then they get added to the document.

I would also recommend both client and server side unit-tests and system tests to ensure conformance to the document.

It may seem like a lot of work, but minor missteps here can be very expensive and time consuming.

• LazerSharks: Ah, happy to learn that there's a whole world dedicated to this aspect. I was thinking this aspect seems like where the rubber really meets the road in terms of the divide between front-end and back-end.

Answer 4

I would just ask Why Not? When we are talking about a project we also talk about the team working on it and it is expected and should be welcomed to hear opinion about the features and and structure used. As a developer I personally believe and value the contributions of teammates.

You know there is a saying "if you want to go fast go alone. if you want to go far go together".