Response cache is fine for simpler operations, but sometimes you need more fine grained control. System.Runtime.Caching.MemoryCache has builtin support for in-memory cache with expiry.
ASP.NET Core comes with built-in support for response caching. Unlike cache-control header that tells client/proxies how long to cache data, the response cache will cache output of an action.
Whether writing stand alone application or web application you may want to put database related code into a separate project. I find it good for separating concerns.
Swagger makes the API machine readable. This means documentation and client implementations can be produced automatically. Swashbuckle runs top of Swagger and provides an UI. Together they provide nice functionality for documenting and testing your API.
With API’s often changing over time you may want to plan for versioning early on. ASP.NET Core has a library that makes versioning API a bit easier. By tagging controllers and actions with version number one can run multiple versions simultaneously.
Having MVC pages and API in the same solution can be beneficial. Projects may share a lot of boilerplate code and settings, is easier to maintain and can access API functions directly through DI (if controllers are registered there) instead of going via HTTP. But you may want to separate both URL and code so it is clear what is MVC and what is API.
With .Net Core we finally got some decent/easy to use config system built in by the help of the Options pattern. In short, reading config by deserializing sections of appsettings.json into DI-hosted objects.