Basic Drawbacks
Excess complexity, redundancy. More potential for bugs (more paths through more code), more time to develop, test, and more cost to maintain, forever.
Stale Data
The moment the data in the database changes from some other source than this service, the server starts returning incorrect (or at least stale) data. You get to experience cache that is inconsistent with persistent data. That's quite educational.
Scale Out and Cache Consistency
As soon as the test app scales to thousands of users (most test apps do that, right?) and you add more servers, you will have a cache consistency problem, where each of those servers has its own copy of that JSON cache, and the copies may give different results to requests.
Concurrent Modification
What happens when many concurrent requests come in from multiple users? How do you insure that each user sees up to date information and that no user's changes are lost? It's quite solvable. The database can provide this service. How will you provide it for JSON? It's a great learning opportunity, but is this your priority now?
But Caching Is Sometimes A Good Idea
There is a place for caching. Sometimes it's needed for performance. If the time to retrieve data from the database is "fast enough" then there's no need for cache.
Maybe Learning Is Your First Priority
You are building a test application. It's your sandbox. If you feel like having an intermediate JSON cache, there is no need to justify it.
Just do it, and learn from the experience.
