The data structure on the front-end and back-end is different. Who should redo?

Question

RESTful API

A non-compliance with the contract occurred during the development of the system module.
The front end works with entities without nested subentities, but the back end only accepts them in this format. On the front, the data is built in such a way that it is convenient to render, and on the back-end - for queries to the database.

export interface someEntity {
  prop: string;
  someMoreProp: string;
  someArr: string[]
}

export interface someBackendEntity {
  prop: string;
  someBackArr: [{
    someMoreProp: string;
    someArr: []
}]
}

Should the data come to the front in the right format, or should it be mapped before each call to the server (actually a nested foreach - which looks somehow too tricky for a simple query)?

Answer 1

On the front, the data is built in such a way that it is convenient to render, and on the back-end - for queries to the database.

And between them - API - in which the data should be in the form of a convenient mutual understanding.
As agreed, as convenient.
What's in the frontend, what's in the backend - these are their internal affairs.
The only point of interaction is the API.
This is the format that is being discussed.

Answer 2

Throw out the backenders and use some kind of serverless solution if they are just a layer in front of the base and can’t even convert data into a format other than a plate for the write model.
Convenience is essentially the main requirement for the API, and Backend problems should remain on the backend.
Ps and even better to estimate costs / benefits instead of unproductive disputes

Answer 3

It's normal that the data structure is different.
APIs are created by the backend and are part of the backend, they are a way for clients (frontends, mobile applications, other backends) to work with the system.
Clients just work with the API. You can’t adapt to all customers, and you don’t need to. The maximum is to listen to wishes.