Stimmt. Den Datenbankserver darf man sowieso nicht erwischen von außen. Die Devart hat(te) dafür ein Beispiel für die Secure Bridge und
SSH Server.
Eine Service verbirgt zumeist eine ungewöhnliche Implementierung. Das Shiften von Implementierungen zwischen ähnlich gelagerten offenen System wie relationalen Datenbank ist eher einfach. Dabei handelt es sich in der Regel eher um den verbreitetsten Spezialfall.
Im Umfeld der Services empfiehlt sich meiner Ansicht nach die Trennung zwischen den echten Spezialfällen und jene 99,999999% die auf dem selben technologischen Weg über eine Schiene abgewickelt werden und das der Behandlung vom verbliebenen Rest in der die Sicht als Service tatsächlich für Transparenz aus Sicht der aufrufenden App sorgt.
Egal kleine ein App sich ausnimmt resp. die Bescheidenheit der gebotenen Funktionalität, ob Service oder nicht hängt stark an der Backendtechnologie und deren Geschlossenheit. Ansonsten muss man beinahe für jede Anwendung einen Treiber anbieten.
Ehrlich gesagt ist das PHP-Tunneling auch nicht viel anders als der REST-Ansatz. Es geht darum das du vom Client, in deinem Fall Android, nicht direkt auf die
DB kannst und stattdessen irgendwo einen Server hast mit dem deine App "über Port 80" kommuniziert und der Server kommt dann an die Datenbank.
Ob du das nun mit PHP machst oder den Server anders aufsetzt, ob das nun REST,
SOAP oder sonst eine "Philosophie" ist, ist ja dann Wurst.
Ehrlich gesagt ist das PHP-Tunneling in Gänze etwas ganz anderes als REST oder
SOAP, denn hier hat sich nur die Übertragungsart geändert, der Inhalt ist der gleiche, als ob man direkt mit dem
MYSQL Server spricht. Ich muss also wissen, wie sich ein
MYSQL-Server verhält, ergo ich muss etwas über die Implementierung wissen.
Bei REST und
SOAP benötige ich kein Wissen über die Implementierung. Selbst ein Wechsel der Implementierung (Datenbank-System) kann hier komplett transparent erfolgen.