The appropriate development depends on your needs. There are two main considerations here:
Development time vs bandwidth
Would you rather waste a bit of bandwidth in favor of speeding up development? Then only develop the full order details endpoint.
Do you want to save bandwidth no matter the cost to development time? Then create an endpoint for each specific subset of order data you need.
Do you want to find a happy balance? Then only develop a few of those endpoints, e.g. a "simple" and "detailed" endpoint. Any view that is "somewhat detailed" will then waste a bit of bandwidth but any view that only needs a simple listing won't. From experience, this usually covers most bases and finds a happy medium.
Backend-driven vs frontend-driven
Does the backend exist to serve the frontend? Or if the backend the main product, and the frontend consumes it? Depending on which is your main project, you make these kinds of decisions differently.
Personally, I consider a backend (especially a REST api) as being a project that defines its own exists, regardless of how a frontend may choose to consume it or not. This means that I don't write custom backend endpoints that serve one specific view from one specific frontend. The backend simply provides the information, and I don't add/change endpoints just because I decided to add/change a single field on a certain page.
But I am a backend developer and I work in companies that deliver a service (i.e. REST api), not a client app.
If your main project is the client app you're developing, and you need to squeeze for performance/bandwidth, then the added effort of altering your backend to suit the precise needs of your frontend may be desirable for you.
As always, precision takes effort, which takes time and money. Whether it's worth it or not very much depends on how necessary it is, and how much time and budget you have available.