The standard practice is to use https for the baseline protection of REST API calls.
Additionally (going beyond standard practice, but preferred by some), selected information that is sent to the server or received from the server, may be further encrypted with AES, etc. For example, if there are sensitive contents, you might choose to select those to encrypt so that even if the https is somehow broken or misconfigured, you have another layer of protection from your encryption. It's easily to think that theoretically, TLS is so rock solid, but there have been various serious vulnerabilities exposed over the years, such as beast, poodle, sweet32. These may only affect certain cipher suites, but if you're not careful with your configuration for allowed TLS cipher suites, you may be vulnerable to one or more of these. Not all server-client pairs support TLS 1.3; it is sometimes said that TLS 1.3 "makes it harder for admins to misconfigure" than earlier versions like TLS 1.2.
In a previous project, a pen tester had requested for encryption of such sensitive contents, even though we were already using https.
The question of key management has been raised by others. If you were to do this, you would definitely not be using one key for every mobile to share. Rather, each mobile and the server should use a unique key. A convenient way to do this is to derive shared secrets at least partly from the push notification tokens, that are unique for each mobile and known by mobile and server (assuming the push notification is sent to the server earlier, say, over TLS alone and unencrypted).
There are other questions on this site that appear to be addressing the same question, but are not exactly, on closer inspection.
1) For this question, even though it is also using https and with a REST API, it is for a web application, not a mobile application. Hence, the accepted answer could rightly say:
For a web app designed to run in the browser, the security value of application layer encryption is basically zero. Why? Because the very code that does the application layer crypto will have to first be transported to the client. If transport layer crypto is broken, that code can be tampered with to the attackers benefit.
An important difference with mobile apps is that application layer crypto code does not have to first be transported to the client. It resides in the mobile app.
2) For this question, no justification is given for asserting that SSL alone is sufficient.
3) This question is concerning protecting data sent over TLS in cases of jailbroken or rooted phones. I agree that in that case, you'd want to focus on anti-tampering mechanisms on the phone, to protect against use of tools like Frida to hook your functions.
4) This question is also addressing a different problem.