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)
4
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.
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.
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.
1
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”.