Q:

Web Applications REST API: Should the data be structured to meet the UI's requirements on the client or on the server?

For a web app I am working on I have a pretty basic relational database. I access this database through a RESTful API and generate the markup in React once the data is retrieved. 
If I find myself constantly manipulating/processing these JSON responses on the client-side just to structure these objects into more friendly structures for my UI, is that a sign that perhaps I am doing too much on the client?
I am relatively new in the industry to begin with and I am more concerned with knowing when I should bring these things up to another developer who is perhaps working on the backend in question.
This perhaps can bleed into a broader question about REST APIs for Web Apps in general:
Should I expect the responses to my data fetches on the front-end be already structured according to the UI's requirements or would I be asking for too much?
A good example of this would be a category list for a 'Products' page. Is it reasonable that I would fetch the total list of products, and then build the category list from that data or should I expect to have an already structured list of the categories, etc. in the response object when I initially set out to fetch the list of products?

A:

It really depends on your target audience for the API.  If you intend on publishing a public API, then you really need to design toward that.  If the API is strictly to support the UI, then let it be built ad hoc.
However, this is one of the uses for GraphQL and Falcor (or others like it).  GraphQL has a higher learning curve, but allows you to map requests for the precise data you need to display across web services.  Your public API remains untouched, and you have this unified query language to consolidate the requests for data into one.  Since GraphQL usually lives in an API proxy of sorts, it allows for some intelligent caching.
It comes with a high learning curve, but you do gain a lot of power for your investment.  Weigh the costs against your needs.  If your API is pretty simple, you can delay looking at this until your needs really do grow complex.

A:

Your approach will depend on whether the web app is the only user of the backend application or not. It may also depend on what your development team (in this case you yourself) are more skilled in: backend or frontend development.
My preference is to have as much logic as possible in the backend app and as little as possible in the frontend. This is due both to my skillset and also to my conviction that business logic is easier to implement and test in the backend (which may be biased, of course).
So what I would do would be:

If your frontend is the only user of the backend app, align all APIs so that they are easy to consume by the UI and provide data as closely fitted to what the UI presents as possible. This way your logic is almost all in the backend (easier to develop and test IMO) and the frontend can concentrate on just presenting the data without dealing with much business logic.
If your backend app has other users apart from the frontend, or you have to communicate with a backend app written by someone elase where you have little control over the API, I would consider writing a Backend-for-Frontend (BfF). A Backend-for-Frontend is a backend app which acts as a proxy between the UI and the "real backend". In this app you can transform the data from the backend's format into a format which is ready to use by the UI. You can then have a very simple frontend app and all business logic in the BfF. Essentially, the BfF is a facade which allows you to use the approach described in previous bullet point when you can't directly change the backend app's API to match the UI.

