web - Json Object in development? Is it decided in front-end or back-end? -

i working on web-app layout getting generated after getting json backend. object recieved backend quite complicated , requires loop around object quite few times layout.

and same happening while posting data backend.

what feel if follow front end layout generate json object post data , if object structure backend changed, layout generation not need loops.

so json object backend gives or should according front-end?

for example backend giving

[   {     "keyid": "value",     "attr1": "value1",     "attr2": "value2"   },   {     "keyid": "value",     "attr3": "value3",     "attr4": "value4"   } ] 

but easy front end receive , send object in format below:

{     "keyid": "value",     "attr": {         "attr1": "value1",         "attr2": "value2",         "attr3": "value3",         "attr4": "value4"     } } 

good question, although closed "too broad".

in general, back-end responsible persisting data, , performing business logic, preparing , accepting packets of data going , front-end, ideal being front-end can limit role, display data, manage navigation, , handle user interaction, doing whatever pre-processing , manipulation necessary accomplish things.

if back-end "does not enough", see front-end needing make many data requests acquire data needs, doing equivalent of "joins" combine , relate data, , performing business logic. slows down front-end , makes more complex, , spreads business logic across back-end , front-end.

on other hand, if back-end "does much", , calculates , provides down point need merely populated html templates, result ends being dependent on specific front-end design, meaning changes require making many modifications both sides.

therefore, 1 attempts strike golden mean. back-end should retrieve necessary data, relate , manipulate it, , perform business logic. provides set of relatively abstract, yet fleshed-out data objects front-end can prepare , manipulate ui. there no hard-and-fast rules draw line.

for example, pagination can considered "ui" issue, , can handled client frameworks, yet if there hundreds or thousands of objects, performance considerations might dictate handling on server. same sorting.

consider calculation of total price of items in shopping cart. front-end kind of business logic, yet there rules such volume discounts or currency conversions best handled on back-end. of course, if calculation done on server, requires round-trip server each time item added cart in order recalculate total. round-trips relatively cheap, in situations again, performance issues might lead 1 want on client in order avoid round-trip.

at end of day, set of design choices. of course, case back-end api "frozen" , front-end people have work given.