Réseau pratique pour les développeurs Android (partie 1)

( 7 nov 2020)

Couche de données facile pour chaque application

Voici la liste des blogs de cette série:

  • ( Partie 1 – HTTP et couche réseau )
  • (Partie 2 – TLS, certificats et épinglage)
  • (Partie 3 – Authentificateurs et intercepteurs)
  • (Partie 4 – Performances, redondance et concurrence)
  • (Partie 5 – Test et intégration)
Réseau pratique pour les développeurs Android

Ceci est la première partie de cette série « Réseau pratique pour les développeurs Android » quand nous allons parler de la couche de données réseau avec une vision différente qui est généralement ladresse d, car la mise en réseau sur Android est difficile à faire fonctionner, avec plusieurs opérateurs, des contenus différents et riches, du streaming et tout cela devrait arriver à nos utilisateurs sans manquer un seul détail

HTTP et couche réseau

Http est un protocole réseau, si vous vous connectez à Internet que vous lutilisez, la jolie version de la définition est que Http est:

« An couche application protocole pour distribué, collaboratif, hypermédia systèmes dinformation « 

Cela signifie un tas de choses, en gros, si vous créez un site Web , application pour smartphone, IoT, même seulement un téléchargement dun fichier, vous utilisez ce protocole, il est passé de pages Web avec du HTML simple à des applications Web en passant par des applications mobiles, a évolué pour devenir une couche API couramment utilisée.

Reques HTTP ts sont générés par nos utilisateurs lorsque lutilisateur interagit avec notre application mobile, nous commençons à demander des informations à un serveur lorsque nous avons fait un clic, peut-être un défilement ou une suppression, par exemple, imaginez Gmail, chaque fois que vous entrez dans lapplication une requête Http est fait pour que les e-mails soient actualisés, si vous supprimez, répondez ou même ouvrez un e-mail, cela générera une requête Http, ces requêtes Http vont à un serveur dorigine ou à un serveur de mise en cache proxy, et ce serveur générera une réponse Http. Habituellement, tout ensemble de requêtes / réponses a:

  • Requête – Faire une requête HTTP à une URL
  • Réponse – La requête renverra une réponse qui peut être une erreur ou un succès.
  • Données pouvant être analysées – Sur mobile, nous devons analyser la réponse à un objet, des données Classe ou Struct que nous pouvons utiliser dans lapplication, en utilisant des tiers comme Moshi, Json, Gson *, vous pouvez même créer le vôtre, mais lorsquil atteint le téléphone, il sagit dune chaîne simple.

Habituellement, toute demande / réponse HTTP a les deux éléments suivants:

  • Uniform Resource Locator: une URL est un emplacement spécifique, une adresse quelque part sur Internet avec un type de méthode spécifique
  • Head ers: Donne le client et le serveur transmettent des informations supplémentaires via HTTP demande ou réponse. Un en-tête HTTP se compose de son nom insensible à la casse suivi de deux points (:), puis de sa valeur.
  • Body: La réponse réelle, une simple chaîne exposant le contenu du corps, ne peut être rien pour une méthode, même une unité par exemple.

Pour chaque demande, nous obtenons une réponse, peu importe si elle na pas abouti, nous avons un code de statut pour le savoir:

  • 1xx – Tout est cool, attendez un peu
  • 2xx – Tout va bien, cest une réponse entièrement successive
  • 3xx —La réponse est ailleurs, vous êtes perdu
  • 4xx— La requête du client est mal rempli, il sagit donc dune erreur du côté mobile
  • 5xx – Le serveur na pas réussi à répondre à une demande correcte, il sagit donc dune erreur du côté backend

Méthodes HTTP

Il existe plusieurs méthodes HTTP

  • @GET: Est utilisé pour lire ou récupérer des informations sur une ressource. Les requêtes GET sont utilisées uniquement pour lire les données et ne pas les modifier, elles sont considérées comme sûres
  • @POST: Est utilisé pour la création de nouvelles ressources. En particulier, il est utilisé pour créer des ressources subordonnées. Nest ni sûr ni idempotent. Il est donc recommandé pour les demandes de ressources non idempotentes.Faire deux requêtes POST identiques entraînera très probablement deux ressources contenant les mêmes informations.
  • @PUT: Est utilisé pour les capacités de mise à jour, PUT-ing vers un URI de ressource connu avec le corps de la requête contenant la représentation nouvellement mise à jour de la ressource dorigine. PUT nest pas une opération sûre, en ce sens quil modifie (ou crée) létat sur le serveur, mais il est idempotent. En dautres termes, si vous créez ou mettez à jour une ressource à laide de PUT, puis effectuez à nouveau le même appel, la ressource est toujours là et a toujours le même état que lors du premier appel.
  • @DELETE: Est utilisé pour supprimer une ressource identifiée par une URL.
  • @PATCH: Est utilisé pour modifier les capacités. La requête PATCH doit uniquement contenir les modifications apportées à la ressource, pas la ressource complète. PATCH nest ni sûr ni idempotent.

Quoi quil en soit, toute modification à lintérieur de lune de ces méthodes pour une application mobile peut être significativement dangereuse, imaginons une application qui reçoit une variable en double dans une réponse , si cela est changé dune manière ou dune autre en booléen, lanalyse des données sera interrompue, cest un énorme écueil que les ingénieurs backend doivent prendre en compte chaque fois quils modifient un point de terminaison qui est consulté en production.

HttpClient

Aujourdhui, la plupart des applications Android reposent sur des API. Une API est généralement un service Web RESTful (peut être beaucoup de choses, est-ce juste un exemple) qui peut être consulté via HTTP et expose des ressources qui permettent à lutilisateur dinteragir avec lapplication, nous avons principalement besoin dun HttpClient pour y accéder sur Internet et commencez à récupérer des données pour nos utilisateurs.

Dans Android, nous avons une incroyable bibliothèque qui crée un HttpClient en quelques secondes, appelée OkHttpClient , cela créera un client, avec un readTimeOut et une ConnectionTimeOut, si le serveur ne fournit aucune réponse dans ce laps de temps, nous nous retrouverons avec une connexion non réussie.
Il y a une partie vraiment importante de ce client, nous pouvons également mettre un constructeur pour Cache (et des tonnes dautres choses dont nous parlerons plus tard dans cette série)

Cache

La récupération des ressources sur le réseau est à la fois lente et cher, la raison principale est que nous dépendons de plusieurs choses dans le mobile, par exemple, sur le réseau de notre utilisateur, de la 5G à la 3G, du WIFI avec fibre optique aux câbles de communication

Le cache est conçu pour rendre les appels réseau meilleurs pour tout le monde, même pour les utilisateurs, car ils se termineront sans demandes réseau inutiles. La capture ne remplacera jamais un appel dorigine à votre DNS, par instance, le cache ne remplacera jamais la récupération des données depuis sa source.

Caching de base de données
Ne concerne pas réellement la couche réseau, nous interrogeons nos API sur les informations et nous les stockons dans SharedPreferences, DataStore ou toute base de données qui peut être relationnelle ou non relationnelle. Les performances, à la fois en vitesse et en débit, fournies par votre base de données peuvent être le facteur le plus déterminant des performances globales de votre application.

Réseau de diffusion de contenu
Lorsque le trafic de votre serveur est mondial, ce nest pas toujours une méthode simple et économique pour répliquer lintégralité de votre infrastructure à travers le monde, et pour cela, nous avons CDN qui vous permet de utiliser son réseau mondial demplacements périphériques pour fournir une copie en cache du contenu de vos API, y compris des images, des flux et des vidéos

Domain Name System
Chaque demande de domaine effectuée sur Internet interroge essentiellement les serveurs de cache DNS afin de résoudre ladresse IP associée au nom de domaine. La mise en cache DNS peut se produire à de nombreux niveaux, y compris sur le système dexploitation, via les FAI et les serveurs DNS.

Pour le réseau en particulier, nous pouvons faire en sorte que notre HttpClient gère le cache (vérifiez le code ci-dessus) et le non-cache, par exemple dans certaines applications, nous pouvons avoir un pull pour actualiser, il peut être nécessaire dignorer le cache et dextraire les données directement du serveur. Pour forcer une actualisation complète, ajoutez le no-cache directement dans votre générateur de cache pour votre OkHttpClient, la décision de faire ce type dappels est particulièrement orientée produit plus que technique pov.

Cest tout pour cette partie du message . Pour la partie suivante, nous discuterons des certificats, de lépinglage et de la TSL!

Si vous avez besoin daide:

Je suis toujours heureux de vous aider, vous pouvez me trouver ici:
Moyen comme
Twitter comme @ddinorahtovar
StackOverflow comme Dinorah Tovar

Bon codage! 👩🏻‍💻