You pass username/password to the login method of your RESTful API and it returns access-token. That access token is just some unique (for the system) string.
Device stores (persists) that access-token. Each time you send RESTful request to the server you put that access-token in header of HTTP request. Server finds the user by access-token and on success fulfills the request.
username/password must not be stored on the device.
The API being designed follows the Rest style of resources-centric URI and CRUD operations mapped to HTTP verbs.
This is your problem right here.
You have limited your resources to (I'm assuming) the models in your database. As such it is taking ages to load all these resources because your server has no concept of resources that don't have a representation in the database.
For example might have
www.example.com/books/482094
www.example.com/books/582045
www.example.com/books/427454
www.example.com/books/319343
that all have to be loaded to get my library
This isn't a problem with RESTful design, this is actual a REST anti-pattern. There is absolutely nothing in REST that says our resources must have a one to one mapping with anything else in your system, including database models.
The solution is to create more resources that better match what you want to load. If you have 5 resources that always end up together create a new resource that contains the info for those 5 resources.
What you should have is something like this
www.example.com/users/334/my_library
which just loads all the books for that user. "my_library" isn't a model in your database, but it is a resource. The server creates it based on models in the database but there is no 1-to-1 mapping and the server has flexibility to create this resource without changing your DB model.
You might also have
www.example.com/users/334/favioured_books
www.example.com/users/334/books_ordered_last_week
www.example.com/users/334/wishlist
none of which have to exist as model in your database or domain space.
There is a wide spread misconception that this is the wrong thing to do because frameworks like Rails taught people to map resources in a 1-to-1 fashion to models in the domain space which map again 1-to-1 with database rows. This is not necessary nor is it recommended.
Resources should be numerous, cheap and lightweight. It should be easy to create them, and they should be abstracted from your domain model. If you find you need a new one you just make a new one. If you have problems doing that it is your frameworks fault not a fault with REST.
Now the big caveat with that of course is whether your framework allows you to do this. Frameworks like Rails and Django which have taken the course to map 1-to-1 in order to "save you time" make it hard to do this. But that is a flaw with the frameworks, not with RESTful design.
Here is Jim Webber discussing this is more detail (including a few digs at Rails as well!)
https://yow.eventer.com/yow-2011-1004/domain-driven-design-for-restful-systems-by-jim-webber-1047
Best Answer
You forgot about POST.
You need to learn a bit more about REST (you actually need to learn a whole bunch of other stuff as well), but suffice it to say that if you want to do any other operation besides a GET, PUT, PATCH or DELETE, it's probably going to be a POST.
Also, note that there are other ways to communicate with a server besides REST. Stand up a WebSocket, and you can pretty much do whatever you want.
In any case, a GET suffices for what you want to do, if you want to stay with REST.