Travailler avec les services Web

Cet article explore les protocoles de service Web, les formats d'échange de données courants et les meilleures pratiques. Si vous souhaitez créer des applications mobiles performantes qui se connectent au Web, lisez la suite.!


Choisir un protocole et un format de données

L'une des décisions les plus importantes à prendre au cours du processus de développement consiste à sélectionner un protocole et un format d'échange de données appropriés pour la transmission de données entre votre application mobile et le réseau. Les protocoles les plus courants et les plus utilisés sont REST, XML-RPC et SOAP..

Tous ces protocoles transportent des données via le protocole HTTP. Les protocoles XML-RPC et SOAP sont basés sur XML, tandis que les services REST peuvent compter sur différents formats de données, les deux plus courants étant XML et JSON. SOAP en particulier est largement apprécié et adopté par les applications d'entreprise car il applique strictement les modèles de données et décrit les interfaces publiques via WSDL, permettant ainsi à certains outils de développement (tels que Microsoft Visual Studio pour .NET) de configurer automatiquement des objets et des méthodes de consommation. les services en ajoutant simplement une référence au service WSDL dans le projet.

Cependant, XML est de par sa conception moins efficace que JSON lorsqu'il fonctionne dans un scénario de réseau à bande passante limitée, tel que le développement mobile. Les réseaux de données mobiles (WWAN) sont généralement moins fiables que les réseaux câblés (LAN) ou sans fil (WLAN), car les clients en déplacement peuvent facilement entrer et sortir des zones de couverture. En outre, certains utilisateurs ne s'abonnent pas aux forfaits de données «fixes» et sont réellement facturés par le trafic réseau..

Ainsi, tout en développant pour le mobile, vous devriez toujours opter pour la simplicité et la réduction du trafic..

Comparons XML simple à JSON avec un exemple de réponse:

XML

  Bonjour, appareil! 

JSON

 returnValue: "Bonjour, appareil!" 

Comme vous pouvez le voir, JSON porte une charge utile plus petite car il lui suffit d’envelopper ses données entre crochets (bouclé pour les objets, carré pour les tableaux) et entre guillemets, alors que XML requiert un nœud racine complet et des balises d’ouverture-fermeture pour chaque élément ou groupe. L'enregistrement sur ces balises peut réduire considérablement la charge utile de la réponse. Plus vous transférez de données, plus le "remplissage" de la charge utile sera avec XML.

De plus, SOAP et XML-RPC nécessitent des structures de données XML plus complexes (comme l’enveloppe «SOAP»), ce qui ajoute un poids supplémentaire à la charge utile..

Pour cette raison, je recommande de choisir JSON pour le format d'échange de données de votre application et DU REPOS pour le protocole de transfert, sauf si XML, SOAP ou XML-RPC sont explicitement requis pour vos besoins. Si vous devez appliquer un modèle de données, vous pouvez le faire également avec JSON en utilisant le schéma JSON ou WSDL 2.0..

Pour des références et des lectures supplémentaires sur les protocoles et les formats de données discutés, consultez les rubriques suivantes:

  • Le débat entre JSON et XML
  • Présentation JSON
  • Présentation XML
  • Présentation XML-RPC
  • Vue d'ensemble de SOAP
  • La page d'accueil JSON
  • Plus sur le WSDL

Considérations sur la sécurité du réseau

Étant donné que la plupart des services Web fonctionnent sur des réseaux publics, la protection des données qui seront échangées entre les services et l'application est l'un des problèmes les plus critiques à résoudre. De nombreux services Web fournissent des fonctionnalités distantes aux utilisateurs authentifiés. Par conséquent, les données personnelles et les informations d'authentification doivent également être transférées sur le réseau..

Les données personnelles, les données de compte et les informations d'identification doivent jamais voyager en clair sur un réseau public, cela signifie donc que vos services Web et vos applications doivent implémenter la cryptographie. La bonne nouvelle est que les protocoles les plus courants transportent des données via HTTP. Vous pouvez donc compter sur bien connu, fiable et robuste Le protocole HTTP SSL / TLS (HTTPS) bénéficiant d'une prise en charge étendue, tant côté serveur que côté client.

Activer SSL sur des serveurs Web courants est assez facile (il existe de nombreuses ressources utiles pour Apache, IIS et Nginx). Tout ce que vous avez à faire est d’acheter un certificat SSL et de l’installer sur votre serveur. Dans un pire scénario, vous pouvez également émettre un certificat auto-signé qui vous apportera un cryptage gratuit, mais je voudrais ne pas recommande de le faire. Certaines autorités de certification émettent des certificats à bas prix et les avantages que vous retirez du travail avec un certificat approuvé et signé valent bien le coût supplémentaire (c'est-à-dire la prévention des attaques interceptives à l'aide de l'infrastructure à clé publique). L'utilisation de certificats auto-signés peut également nécessiter un codage supplémentaire ou même des «hacks» spécifiques à l'application, dans la mesure où certaines bibliothèques réseau refuseront les connexions HTTPS non fiables (consultez ces articles sur Android, n ° 1 et n ° 2 et sur iOS)..

L'activation de SSL côté client est une évidence: les langages de programmation courants ont généralement des classes et des bibliothèques HTTP qui fournissent un support natif HTTP-SSL et s'occupent "automatiquement" du chiffrement en utilisant simplement les URL "https: //" au lieu de "http : // "URL à utiliser des services Web.

Si vous optez pour un certificat SSL peu coûteux, assurez-vous simplement que les certificats et systèmes d'exploitation pour lesquels vous souhaitez développer le certificat racine de l'émetteur de l'émetteur sont regroupés immédiatement, sinon ils ne feront pas confiance au certificat..

Vous ne devez jamais demander aux utilisateurs de corriger, modifier ou pirater leurs systèmes afin de faire fonctionner vos applications. Si vous le faites, n'attendez pas que beaucoup d'entre eux se conforment.

Authentification du service Web

Authentification pour les services basés sur REST

Authentification basée sur les jetons

Les transactions de services Web sont censées être atomique, interopérable et évolutif, alors les services Web sont généralement apatride (Cochez cette discussion intéressante sur la signification des connexions "sans état").

De nombreux services Web fournissent des fonctionnalités liées à l'utilisateur et permettent d'accéder à des informations sensibles. Naturellement, cela nécessite une authentification. Comme ces transactions sont sans état, il était généralement nécessaire de signer des demandes avec une clé spécifique à l'utilisateur, en fournissant une authentification pour chaque appel de méthode distant. Même lors du transfert de données via HTTPS, les informations d'identification de l'utilisateur sont les plus à risque lorsqu'elles sont transmises sur un réseau public. Le chiffrement est parfois cassé.

Ce dilemme est celui où l’authentification à base de jetons telle que OAuth est utile. À l'aide de l'authentification par jeton, vous devez envoyer les informations d'identification d'un utilisateur une seule fois. Si l'utilisateur est authentifié avec succès, des jetons lui seront fournis pour authentifier les appels de méthode distants suivants..

La validité d’un jeton s’étale sur une durée de vie limitée et peut être révoquée à tout moment par son émetteur (c’est-à-dire côté serveur). Avec l'authentification par jeton, vous pouvez également partager les mêmes informations d'identification utilisateur entre différentes applications et services sans que les services / applications liés ne connaissent jamais les informations d'identification de l'utilisateur réel. En outre, cette méthode d'authentification conserve en toute sécurité un cache local des informations d'identification sur le périphérique de l'utilisateur, de sorte que l'utilisateur puisse être "mémorisé" et qu'il ne soit pas nécessaire de s'authentifier à chaque fois qu'il utilisera l'application (la saisie de mots de passe complexes sur des ordinateurs de poche peut être un réel problème. douleur et peut endommager gravement les critiques d'applications).

Authentification basée sur OAuth

OAuth est le cadre d'authentification basé sur les jetons le plus courant et a été adopté par de grands acteurs tels que Google, Twitter, Facebook, etc. En permettant aux utilisateurs de réutiliser leurs comptes existants, en éliminant les formulaires d'inscription gênants et en gardant le contrôle de l'accès à leurs données personnelles, vous pouvez augmenter considérablement votre base d'utilisateurs..

Certains fournisseurs OAuth exigent que leur propre SDK soit importé dans vos applications pour permettre l'authentification. Sinon, vous pouvez connecter de nombreuses bibliothèques OAuth prêtes à l'emploi que vous pouvez connecter à votre application. Il existe également des cadres tels que oauth-php disponibles pour créer des fournisseurs OAuth personnalisés.

Je suggérerais indicateur comme une bibliothèque client Android OAuth et oauthconsumer pour iOS.

Toutes ces bibliothèques viennent avec des exemples utiles et sont faciles à implémenter. Toutefois, la création des sources de panneaux sur votre machine ou leur importation dans votre application peut s'avérer un peu pénible, mais vous n'avez pas réellement besoin de suivre ce processus. Au lieu de cela, vous pouvez simplement importer les fichiers binaires JAR dans votre projet et vous devez les définir. Sur iOS, cela ressemblerait à importer une bibliothèque statique (fichier * .a) dans votre projet..

Authentification pour les services SOAP

La méthode d'authentification la plus courante pour les services SOAP est une extension SOAP appelée Authentification de base HTTP (parfois appelée Authentification Digest). Il s'agit d'une procédure standard, bien prise en charge, intégrée à tous les serveurs Web les plus courants tels qu'Apache, Nginx et IIS. Il est basé sur une paire nom d'utilisateur / mot de passe qui doit être envoyée au serveur via des en-têtes HTTP..

Normalement, vous n'avez pas à implémenter manuellement l'authentification de base dans vos applications, car elle est également largement prise en charge dans les langages de programmation les plus courants. Le framework .NET s'appuie sur la classe NetworkCredential pour fournir des informations d'authentification de base et de synthèse aux demandes HTTP, PHP le prend en charge via cURL et Java via Authenticator..

Si vous devez implémenter l'authentification de base vous-même, il vous suffit d'ajouter cet en-tête à vos demandes:

 Nom d'utilisateur de base: mot de passe

Les valeurs «nom d'utilisateur» et «mot de passe» doivent être codé en base64.

S'il vous plaît noter que HTTP Basic Auth est préférable d'utiliser en combinaison avec le protocole HTTPS, comme il transfère les informations d'identification dans texte en clair forme. Digest Auth est un peu plus sûr, car il hache la valeur du mot de passe, mais HTTPS est néanmoins recommandé pour éviter les attaques par hachage par force brute..

Plus de détails et de spécifications sur ce sujet sont disponibles dans le mémo IETF RFC 2617.

Bibliothèques d'authentification de plate-forme native

Lors du choix d'une méthode d'authentification ou de l'intégration de services connus (tels que les réseaux sociaux), vous devez également prendre en compte les bibliothèques natives intégrées à de nombreuses plates-formes avancées telles qu'iOS et Android. Cela peut vous faire économiser beaucoup de temps et de nombreuses lignes de code..

Android fournit un cadre agréable pour centraliser la gestion des comptes d'utilisateurs, la classe AccountManager. Le guide officiel du développeur Android fournit une documentation intéressante pour cette classe, ainsi que des astuces pour intégrer OAuth 2 ou écrire votre propre "Type de compte personnalisé"..

Avec iOS 6, Apple a introduit un nouveau cadre social pour intégrer des services majeurs tels que Twitter, Facebook et Sina Weibo au niveau du système d'exploitation. Même si vous n'avez pas besoin d'intégrer ces services dans votre application, vous pouvez trouver un moyen approprié de tirer parti des méthodes d'authentification intégrées via la personnalisation..


Conseils d'optimisation

Compression de données

Lors du développement d'applications mobiles, il est important de garder vos charges utiles de données aussi basses que possible. Cette section discutera de plusieurs stratégies pour le faire.

Archivage des données

Compression ZIP peut considérablement réduire le poids du texte ainsi que le poids des données binaires, et est bien pris en charge sur la plupart des plates-formes. Utilisez-le donc correctement si vous devez transférer des données volumineuses sur des réseaux mobiles. Des bibliothèques utiles pour gérer les fichiers ZIP sont disponibles pour Android (Décompresser, par exemple) et iOS (Ziparchive)..

Diffusion multimédia efficace

Si vous avez besoin de diffuser du contenu audio / vidéo sur vos applications mobiles, choisissez des plateformes de diffusion avancées qui leur permettent de redimensionner les flux en fonction des performances du réseau / du périphérique, telles que le protocole HTTP Live Streaming (HLS) d'Apple. Sinon, privilégier la réactivité au détriment de la qualité des médias est généralement un bon choix. Jouez avec différents compresseurs et paramètres vidéo et audio, en optimisant au maximum. Vous pouvez également regrouper les appareils par type (ordinateurs de poche à petit écran, ordinateurs de poche à écran large et tablettes) et proposer un contenu différent pour chaque type..

Le problème avec la HD

De nombreux appareils mobiles comportent des écrans HD, mais le contenu HD sur de petits écrans vaut-il vraiment la surcharge de bande passante supplémentaire? Soyez honnête sur la pertinence de la qualité multimédia dans vos applications et essayez de trouver le meilleur équilibre entre qualité et poids.

Caching local

Supposons que vous codiez une application de lecture pour un journal en ligne. Tout d'abord, vous devez toujours laisser vos utilisateurs opérer hors ligne chaque fois que cela est possible. Certaines applications nécessitent toujours un réseau actif (services de messagerie, par exemple), mais beaucoup d’autres ne devraient utiliser le réseau que pour télécharger des paquets de données et les mettre en cache sur l'appareil.

Cela améliorera les performances des applications, permettra aux utilisateurs d'économiser de l'argent sur des forfaits de données mobiles non plates et rendra l'application utilisable lorsque le réseau n'est pas disponible (par exemple pendant le vol)..

Lors du téléchargement de contenu sur des appareils sur lesquels un stockage externe est monté (par exemple, des cartes mémoire), vous devez laisser les utilisateurs choisir où stocker le contenu téléchargé (par exemple, stockage interne ou externe) ou simplement préférer le stockage externe. Les périphériques d'entrée de gamme disposent généralement d'un stockage interne plutôt réduit et peuvent devenir instables ou ralentir lorsque le stockage interne est saturé. Si vos applications occupent beaucoup d’espace de stockage, elles seront probablement désinstallées pour économiser de la place..

Chunking Data

Revenons à l'exemple de l'application de lecture. Chaque article est un article unique et, bien que les articles puissent être liés, il n’ya aucune raison pour que vous ne laissiez pas les utilisateurs commencer à lire des articles même pendant le téléchargement de contenu supplémentaire. Emballez donc les fichiers de chaque article (texte, images, pièces jointes et supports) dans archives ZIP séparées et fournir une méthode de service Web pour que l'application récupère le liste des articles disponibles. Demandez à votre application de télécharger des packages ZIP un par un puis les rendre disponibles dans l'application dès que chacun a été téléchargé et pendant que d'autres sont téléchargés en arrière-plan. Il s'agit d'une amélioration des performances et de l'expérience utilisateur par rapport à l'attente du téléchargement complet de la charge utile! Vous pouvez également laisser les utilisateurs choisir les packages qu'ils souhaitent télécharger ou non (leur permettant d'économiser de l'espace, du temps et du trafic) et leur permettre de supprimer des packages individuels pour économiser de l'espace de stockage sans supprimer l'ensemble de l'application.

Voici une réponse de l'application de démonstration fournie avec cet article:

 apiversion: 1, status: 0, packages: [fichier: "pack01_01_01.zip", package: "pack01", version: 1, révision: 1, fichier: "pack01_02_01.zip", package: "pack01" , version: 2, révision: 1, fichier: "pack02_01_01.zip", package: "pack02", version: 1, révision: 1]

Gestion du changement

Gardez à l'esprit que votre application et le contenu précédemment publié pourraient évoluer avec le temps..

Fournissez un indicateur "révision" pour chaque package de la méthode de liste. Il vous sera utile pour publier les mises à jour, corriger les bogues dans le contenu et implémenter la fonctionnalité de mise à jour automatique dans vos applications. Même si vous ne prévoyez pas actuellement de mettre à jour la mise à jour automatique, réfléchissez et placez le drapeau de révision dans votre liste pour tout développement ultérieur..

Vous devez également inclure un indicateur "app-version" dans votre liste de paquets. Si vous publiez une nouvelle version majeure de votre application qui apporte des modifications de dernière génération au format du contenu, cela vous permettra de fournir du contenu pour les applications les plus récentes et les plus anciennes via le même service Web..


Tolérance aux pannes et récupération de données à distance

Tout en développant des applications basées sur le service, réseau et appareil tolérance aux pannes devrait également être pris en compte. Les connexions de données mobiles sont généralement moins stables que celles câblées, les applications peuvent être désinstallées et réinstallées et les appareils peuvent être perdus, remplacés par des plus récents ou restaurés en usine. Les utilisateurs devraient avoir la possibilité de restaurer facilement les applications et le contenu, et les développeurs de plates-formes proposent plusieurs solutions prêtes à l'emploi et utiles à ces problèmes..

Surveillance du statut du réseau

Se souvenir de toujours vérifier l'état du réseau avant d'appeler des services distants, ou traitez soigneusement les erreurs d'E / S réseau et informez correctement vos utilisateurs lorsque la tâche souhaitée ne peut pas être accomplie en raison de l'absence de connexion de données active. Si vos applications doivent toujours «travailler en ligne», vous pouvez mettre en place un chien de garde qui surveille en permanence l'état du réseau et déclenche un événement chaque fois qu'un changement se produit. Vous pouvez également informer les utilisateurs des éventuels coûts supplémentaires liés au transfert de grandes quantités de données via des réseaux 3G ou itinérants plutôt que via le Wi-Fi..

Sur les appareils Android, cette tâche peut être accomplie via ConnectivityManager et SCNetworkReachability sur iOS (consultez également l'exemple d'application fourni)..

Restaurer le contenu et les paramètres

Android et iOS fournissent tous deux des API utiles pour gérer la sauvegarde dans le cloud à distance des données des applications utilisateur. Consultez la documentation de l'API iCloud pour iOS et celle du service de sauvegarde Android pour Android. Avec les services de sauvegarde intégrés, vous obtenez également de bonnes fonctionnalités de sécurité des données. Cependant, vous devez veiller à ne pas surcharger les services de sauvegarde avec des sauvegardes redondantes ou inutiles..

Vous pouvez également implémenter une sauvegarde de données à distance personnalisée dans vos services Web, mais je vous recommande vivement de vous en tenir aux normes et aux API de plate-forme intégrées. Ils vous feront généralement gagner du temps et sont activement entretenus par les ingénieurs en logiciel de plate-forme. Les correctifs de système d'exploitation sont également plus susceptibles d'être installés rapidement une fois publiés..

Restauration des achats intégrés

Si vous diffusez du contenu payant via la facturation intégrée à l'application, autorisez les utilisateurs à récupérer leurs achats après la réinstallation de l'application et la récupération des périphériques est obligatoire. Heureusement, iOS et Android ont des API intégrées pour gérer ce scénario ainsi.

Lorsque vos applications compatibles avec l'achat via l'application sont exécutées pour la première fois (ou pour la première fois après une réinstallation), vous devez exécuter une procédure de vérification achat-restauration. IOS et Android fournissent tous deux une documentation officielle intéressante à ce sujet..

Lors du développement pour Android, rappelez-vous que seuls les éléments «gérés» peuvent être restaurés ultérieurement et qu'ils ne sont disponibles que pour un achat ponctuel. Cela implique certaines considérations qui s'appliquent également au développement iOS..

Supposons que vous développiez un jeu de rôle et que vous souhaitiez permettre aux joueurs d'acheter des articles tels que des potions de santé par le biais de la facturation intégrée à l'application. Tout d'abord, étant donné que les utilisateurs peuvent acheter autant de potions qu'ils le souhaitent, ils ne peuvent pas être «gérés», de sorte que leurs transactions d'achat ne sont pas stockées de manière permanente. De plus, si un utilisateur achète 20 potions et en utilise 10, puis désinstalle et réinstalle le jeu ultérieurement, la restauration des achats à l'aide d'une procédure simple et standard remettrait 20 potions dans son inventaire, 10 d'entre elles constituant un cadeau gratuit non intentionnel. les développeurs.

Par conséquent, vous devrez peut-être implémenter vos propres méthodes Web Services et applications personnalisées pour gérer le stockage et la récupération des transactions dans des scénarios complexes ou des cas périphériques..


Concevoir pour l'avenir

Les échéances et les budgets vous coupent souvent la langue et ne vous permettent pas de suivre toutes les meilleures pratiques expliquées dans cet article. Mais même si vous êtes obligé de vous en tenir à un plus petit sous-ensemble de fonctionnalités, penser en avant, passer du temps dans un bon design, et emballer vos méthodes et classes dans les bibliothèques que vous pouvez réutiliser et étendre plus tard. Laissez les talons lorsque vous sentez qu'il y a place pour un développement ultérieur. Essayez également de faire respecter rétrocompatibilité lorsque vous étendez et améliorez vos bibliothèques, de sorte que les anciennes applications puissent également être corrigées.

Voici un exemple de talon:

 void public sendData (Object data) if (validate (data)) client.send (data);  // Stub public boolean validate (Object data) // TODO - Implémentation de la validation des données return true; 

Conclusion: où aller d'ici?

Si vous êtes un développeur débutant ou que vous n’avez jamais développé d’applications basées sur un service, vous devez commencer par l’exemple d’application fourni, ce qui vous permettra d’améliorer vos connaissances et de le transformer en une application réelle appliquant tous les concepts expliqués dans cet article. temps. Sinon, démarrez une nouvelle application à partir de zéro et intégrez-la avec un fournisseur de services existant (Facebook, Twitter, Last.fm ou Dropbox serait un bon point de départ) en suivant le même calendrier..

Si vous avez déjà développé des applications de service et réseau, vous pouvez réviser votre code existant et l'améliorer conformément aux principes expliqués ci-dessus, en gardant une trace de chaque amélioration et de son impact sur les performances et la réactivité..

N'oubliez pas de consulter également les ressources liées, car elles vous permettront de mieux comprendre le cœur de chaque problème et de télécharger les exemples d'applications serveur et client fournis avec l'article..