I think both approaches are realistic possibilities. With each approach you are probably going to use an anti-corruption layer to translate from the old system to your new code. As you are probably aware now, this will allow your new code be clean, domain-focused, and able to evolve as you gain new domain insights.
In your situation, I'd expect the most important factors to be how much extra effort is involved, what is your longer-term plan, and what are your schedule requirements.
For example, if you put a JSON API on top of your legacy system, a lot of the business rules and calculations may already be implemented. However, if you go direct to the database, you may have to re-implement them.
But if you do go direct to the database, you have effectively replaced that portion of legacy code, meaning there is less of the legacy system that needs to be maintained, understood, replaced, debugged etc.
However, going to the DB comes at the cost of additional risk - you may not reimplement the new version as-per the old one, and additional time - it may take longer, since you are starting from scratch which may push back the delivery of important business functionality.
I'd expect that in most rewrite scenarios creating a JSON API is likely to take longer to eventually replace the old system, but will allow you to deliver new features sooner and more predictably in the short-term. However, that's not a universal rule.
Last edited by nick_t; May 21st, 2015 at 04:50 AM..