Version rapide :
Utilisez une couche intermédiaire de service Web exécutée sur un hôte public que vous contrôlez (éventuellement, mais pas nécessairement, l'hôte de la base de données). Exposez les méthodes de service Web public pour effectuer le travail limité que vous souhaitez autoriser et rien d'autre.
Questions connexes :
- Pilote JDBC PostgreSQL avec Android
- Comment se connecter à un serveur PostgreSQL via JDBC sous Android ?
Options de mise en œuvre
Personnellement, j'utiliserais un serveur d'application Java comme Apache Tomcat ou JBoss AS 7 et j'écrirais mes méthodes de service Web en utilisant JAX-RS pour produire une belle API de style REST que mon application pourra utiliser. C'est ce que je connais et cela fonctionne bien, mais vous avez beaucoup d'options, y compris des implémentations de :
-
API de type REST (JAX-RS impls Jersey et RESTEasy de Java, divers autres outils de langage) qui utilisent des requêtes HTTP et produisent des réponses JSON ou XML.
-
SOAP avec WSDL, la couche "web service" classique. En Java fait avec JAX-WS entre autres options. La plupart des langages ont des outils pour SOAP + WSDL, mais c'est un peu merdique à utiliser, en particulier sur des appareils connectés par intermittence comme les mobiles.
-
XML-RPC si vous aimez la douleur
Il existe des guides de démarrage rapide pour JAX-RS sur les démarrages rapides JBoss AS 7 liste; recherchez simplement "JAX-RS". Le "évier de cuisine " le démarrage rapide est utile, mais peut-être pas idéal si vous n'êtes pas familier avec les bases de JBoss AS 7 et Jave EE 6. Fort des spécificités de JAX-RS, vous feriez mieux d'utiliser un tutoriel Jersey ou RESTEasy comme ceci ou ceci .
Considérations importantes
Utilisez HTTPs si possible, et si l'accès ne doit pas être public, utilisez un schéma d'authentification HTTP approprié comme HTTP Basic auth over HTTPs. Toute implémentation de services Web décente offrira des options d'authentification ou prendra en charge celles de la plate-forme sur laquelle elle s'exécute. Évitez la tentation d'implémenter votre propre authentification et gestion des utilisateurs au niveau des services Web, vous le ferez bousiller; utilisez l'authentification au niveau de la couche HTTP déjà écrite et testée. Cela peut nécessiter l'utilisation de quelque chose comme mod_auth_pgsql d'Apache , les domaines de sécurité JDBC de JBoss AS 7, etc. Le seul cas que j'envisagerais de ne pas faire correctement l'authentification HTTP par utilisateur est celui où je n'ai pas besoin de séparer mes utilisateurs pour des raisons de sécurité, je me soucie seulement que ce soit mon application qui accède au serveur , c'est-à-dire si mes exigences de sécurité sont assez faibles. Dans ce cas, j'utiliserais un nom d'utilisateur/mot de passe fixe pour l'ensemble de l'application et éventuellement un certificat client X.509 si Android les prend en charge.
N'oubliez pas que, quelle que soit la manière dont vous sécurisez les éléments, toutes les informations d'identification sont connues de l'utilisateur ou peuvent être extraites de manière triviale d'un .apk. Vous devez donc supposer que n'importe qui peut accéder à vos méthodes de service Web, pas seulement à votre application. Écrivez-les en conséquence.
Ne pas envoyez simplement SQL depuis votre application via un appel de service Web au serveur et renvoyez les résultats au format JSON. C'est horriblement peu sûr, ainsi que laid et maladroit. Écrivez une méthode de service Web pour chaque tâche individuelle que vous souhaitez que l'application puisse exécuter et conservez le SQL sur le serveur. N'oubliez pas d'utiliser des requêtes paramétrées et faites attention aux autres risques d'injection SQL. Ces méthodes de service Web peuvent utiliser une ou plusieurs requêtes pour produire une seule réponse - par exemple, vous pouvez collecter un enregistrement "Client" et tous les enregistrements "Adresse" et "Contact" associés, puis renvoyer le résultat dans un joli objet JSON l'appareil Android peut consommer, ce qui évite de nombreux allers-retours réseau lents et peu fiables.
Peu importe ce que vous utilisez, assurez-vous de faire vos appels de service Web dans un thread de travail en arrière-plan et de ne pas bloquer l'interface utilisateur. Soyez prêt pour les délais d'attente et les erreurs, et pour le besoin de nouvelles tentatives. Testez votre application en simulant une perte de connexion intermittente, une latence élevée et des taux élevés de perte de paquets, et assurez-vous qu'elle reste utilisable.
