API is way better than a direct mysql communication of your app and the DB server

- direct communication exposes login credentials to each of your users. Once the credentials are decrypted you need to invalidate them and update all app installations (apps: wireshark, mitmproxy)
- api communication: credentials are based on the per-app-UID you can calculate on installation. Credentials could get invalidated on your server and make individual apps either show error or generate a new credential. Each app gets its own credential
- direct communication allows some kind of efficient data transfer, as you do not need to convert the data to "json/xml/binarystream" first but just query it "raw"
- api communication allows modification/optimization of your DB layout/structure without affecting the individual app installations - an "api/gameentry/1" returns the same forever (on same api incarnation)
- api makes things abstracted/more manageable: Deserialization, Sanitation and there you go.
- api makes things "cacheable" (information like api/gameentry/1 could get returned from a RAM-Stream - when using a JAVA appliance, or using flat files from a CDN or whatever)
- direct communication only allows caching via temporary tables or local caches (which could get used by API too)
- api allows easy integration of the same data into webviewers (statistic pages ...)

Only reasons to have direct-mysql-support in your app (I can imagine of): local databases and dynamic connectivity (using adjustable database urls). For local databases "sqlite" will most often be sufficient enough (and it only needs 1 file + 1 temporary one when lock-writing)

bye
Ron