As others have said any API key you send down is open to scrutiny.
The only way to get around it is if you dynamically generate the single page app API key, this somewhat negates the benefit of even doing a single page app (e.g. being able to store the entire "site" on a CDN or something like S3). Also being able to store it offline via Application Cache.
If you can generate the page you can have the generator script take the client's IP and an expiration time (e.g. +1 day), and then encrypt it using strong modern encryption (e.g. AES 256). The encrypted string is the "API key." The single page app then sends it to your REST service which decrypts it using the same encryption key, and checks the IP address against the requester, and the time against the expiration time.
If someone wanted to abuse your REST API they would have to route API requests through their own servers, which would then have to make a request for your single page app, extract the encrypted key, and then make the endpoint REST API request on the client's behalf. This is however easy to detect, just by looking at the same IP(s) connecting over and over.
Plus counter-measures to abuse would be easy to implement and likely effect.
But ultimately this breaks the whole single page application concept completely, and when it is all said and done you may have well have just saved yourself the headache and keep the API key server side. If you're using a third party REST service then everything I said above is irrelevant.
PS - This comment has so many caveats that it is barely useful.