What is the best way to organize access to the REST API

Question

API

I am writing a REST API for a web service, NodeJS + MongoDB + Redis bundle. There are three categories of methods in the API:
1. Public (lists of products, users, etc.), which are used directly on the site, including unauthorized users (ajax loading offsets with products, users, loading tooltips, etc.)
2. Polymorphic, such as getting information about a specific user. Moreover, if a user on the site requests his profile, a more detailed answer should be returned to him (the number of personal messages, for example, etc.)
3. Private - access to PUT, PATCH, DELETE methods only for users who have the right to data), also for administrators - access to all methods.
Authorization on the site occurs via OAuth, it is supposed to be left on the main domain (site.com/login)
The API will be located on a separate subdomain api.site.com. Without cookies, sessions, etc. (according to Feng Shui).
Most articles recommend at least using API keys (they can abuse and all that, the key is locked and everything is fine). The option is good, but what about caching? The same url, but with a different key in a GET request for nginx will look like a different page. Although the data itself is the same.
My head is a complete mess. And you need to cache properly (in the current version of the engine, a bunch of bots are operating, which parse bare html and create tons of garbage activity on the site) and at the same time, access control correctly (administrators have full rights, users only have access to their data, anonyms - only public methods ).
The keys will glow in requests, also a minus, but there was an idea to sew ip into the key so that it was impossible to use someone else's key from another machine, and bind the keys accordingly to users. Banned the user - the key stopped working automatically.
In general, comrades, I think many here have experience. Tell me how to be?

Answer 1

keys are passed in headers, not get/post parameters. So caching is no problem.