Static files as API GET targets



New Member
I'm creating a RESTful backend API for eventual use by a phone app, and am toying with the idea of making some of the API read functions nothing more than static files, created and periodically updated by my server-side code, that the app will simply GET directly.

Is this a good idea?

My hope is to significantly reduce the CPU and memory load on the server by not requiring any code to run at all for many of the API calls. However, there could potentially be a huge number of these files (at least one per user of the phone app, which will be a public app listed in the app stores that I naturally hope will get lots of downloads) and I'm wondering if that alone will lead to latency issues I'm trying to avoid.

Here are more details:
  • It's an Apache server
  • The hardware is a hosting provider's Linux VPS servers with about 1GB memory and 20GB free disk space
  • The average file size (in terms of content and not disk footprint) will probably be < 1kb
  • I imagine my server-side code might update a given user's data once a day or so at most.
  • The app will probably do GETs on these files just a few times a day. (There's no real-time interaction going on.)
  • I might password protect the directory the files will be in at the .htaccess level, though there's no personal or proprietary information in any of the files, so maybe I don't need to, but if I do, will that make a difference in terms of the main question of feasibility and performance?
Thanks for any help you can give me.


Top Contributor
I would have suggested to cache them (and even to use a CDN to do it as it's how I'm handling it) but my exact setup might be different from what you'll end up doing.

I'm basically doing "signed URLs" so it's "password protected" but can be cached at the CDN level easily.
For the updates, you might have to tell the CDN the file was updated, or not. There are many ways to do it
Top down