Normally we don't want to share all of that information with anybody, so we cannot export all of that just the current page we are in.
There is nothing wrong with storing the whole resource on the client and then pushing it up to the server to change the state on the server. If you are worried your resources are getting too large though you could break the resources out a bit. So say you have an order resource and that needs to associate with an address. You don't need to put the address in the order resource, just a link to the address to use. The user can add or alter that address independently. So you might have something like
www.myapi.com/users/1234/shippingaddresses/default
And the client can PUT a new address to this resource. Then in the body of the order resource you can have a link to this resource
POST www.myapi.com/users/1234/orders
{
...order information...
"shipping_address": "www.myapi.com/users/1234/shippingaddresses/default"
}
To be RESTful the client should not build that URL, it should have been given it by the server at some point in the recent past, possibly when the users is selecting which address to use. For example, in the previous step the client could have requested all addresses
GET www.myapi.com/users/1234/shippingaddresses
And presented the list of addresses to the user in a drop down list.