How is it more competent to return database SQL entities with relationships within the REST-api?

Question

RESTful API

I am writing a food delivery app.
On the server side, there is a table of orders - Orders of the following form:

CREATE TABLE orders(  
  id            INTEGER PRIMARY KEY,  
  created_time  DATETIME
);

...and the OrderStatuses table , where we store the order status log:

CREATE TABLE order_statuses(  
  id            INTEGER PRIMARY KEY,  
  created_time  DATETIME,
  status_code   INTEGER,
  order_id      INTEGER,
  FOREIGN KEY(order_id) REFERENCES orders(id)       
);

...those. statuses refer to orders by foreign key.
Following REST, we could do the following to get these entities:

/orders - для заказов

/orders/{order_id}/statuses  - для статусов конкретного заказа

Question: will it be correct to return orders along with their statuses on request /orders (using JOIN in SQL)?
Or is it better to pull two requests on the client side, followed by data merging in the client code?

Answer 1

rest is a fuzzy thing, there are no rules carved in granite.
if you need a status in an order, then give it along with the order.

Answer 2

https://fractal.thephpleague.com
allows you to include related entities like
/orders?include=client
but this is usually done for one-to-one, many-to-one relationships
relationships for one to many relationships, I usually do /orders/{order_id}/ statuses
if statuses depends hard on order does not exist without it.

Answer 3

HATEOAS
HAL

Answer 4

You can do JOIN with pagination (batch request).
For example, "return a list of orders and statuses for X-records of orders in the amount of N".