Você pensa é mais simples e rápido fazer isso com JDBC porque você não está considerando o ambiente operacional do mundo real de telefones e dispositivos portáteis. Eles geralmente têm conectividade flakey por meio de proxies de reescrita de tráfego com bugs e firewalls insanos. Eles normalmente usam uma camada de transporte de rede que tem taxas de perda de pacotes altas e variáveis ​​e latências que variam em muitas ordens de magnitude em curtos períodos de tempo. O TCP realmente não é ótimo neste ambiente e, particularmente, luta com conexões de longa duração.

O principal benefício de um serviço da Web é que ele:

• 
  Tem conexões de curta duração com estado mínimo, por isso é fácil voltar para onde você estava quando o dispositivo alterna redes Wi-Fi, de/para celular, perde conectividade brevemente, etc; e
  
• 
  Pode passar por todos, exceto pelos proxies da web mais terríveis e draconianos
  

Você irá rotineiramente encontrar problemas com uma conexão JDBC direta. Um desafio é o tempo limite de conexões inativas, restabelecendo sessões e liberando bloqueios mantidos pela sessão antiga (já que o servidor pode não decidir que está inativo ao mesmo tempo que o cliente). Outra é a perda de pacotes, causando operações muito lentas, transações de banco de dados de longa duração e problemas consequentes com durações de bloqueio e tarefas de limpeza transacionais. Você também encontrará toda variedade de proxy e firewall insanos e quebrados sob o sol - proxies que suportam CONNECT mas depois assume que todo o tráfego é HTTPs e desmonta-o se não for; firewalls com rastreamento de conexão com estado de buggy que faz com que as conexões falhem ou entrem em um estado zumbi entreaberto; todos os problemas de NAT que você possa imaginar; portadoras "utilmente" gerando TCP ACKs para reduzir a latência, não importando os problemas que causam com a descoberta de perda de pacotes e o dimensionamento de janelas; bloqueio de porta maluco; etc.

Porque todos usa HTTP, você pode esperar que funcione - pelo menos, com muito mais frequência do que qualquer outra coisa. Isso é particularmente verdadeiro agora que os sites comuns usam o estilo de comunicação REST+JSON mesmo em aplicativos da web para dispositivos móveis.

Você também pode escrever suas chamadas de serviço da web para serem idempotentes usando tokens de solicitação exclusivos. Isso permite que seu aplicativo reenvie solicitações de modificação sem medo de executar uma ação no banco de dados duas vezes. Consulte idempotence e definindo idempotência .

Sério, o JDBC de um dispositivo móvel pode parecer uma boa ideia agora - mas a única maneira que eu consideraria seria se os dispositivos móveis estivessem todos em uma única rede WiFi de alta confiabilidade sob meu controle direto. Mesmo assim, eu o evitaria por razões de gerenciamento de desempenho do banco de dados, se pudesse. Você pode usar algo como o PgBouncer para agrupar conexões entre muitos dispositivos no lado do servidor, para que o pool de conexões não seja um grande problema, mas a limpeza de conexões perdidas e abandonadas é, assim como o tráfego tcp keepalive necessário para fazê-lo funcionar e o tempo parado transações de conexões abandonadas.