Utilisation de HttpClient
Dernière mise à jour
Dernière mise à jour
HttpClient
HttpClient
est un service Angular ; on peut donc le récupérer avec la .
On obtient l'erreur suivante No provider for HttpClient!
car le service HttpClient
n'est pas encore et il faut donc importer le module associé HttpClientModule
.
Etant donné que le service HttpClient
est stateless, nous pouvons importer le module HttpClientModule
directement dans notre BookModule
.
HttpClient.get
& co.Nous pouvons donc récupérer les données par API dans le "lifecycle hook" ngOnInit
.
subscribe
En inspectant le comportement du "browser“, on peut remarquer que la requête n'est pas envoyée.
En effet, les méthodes get
, delete
, patch
, post
, put
, request
etc... retournent toujours un Observable
.
Cet Observable
est "lazy" et il faut donc subscribe
pour déclencher le traitement.
Lors de la compilation, TypeScript ne connait pas le type des données retournées par l'API.
Par défaut, la méthode get
retourne un objet de type Observable<Object>
. C'est à dire que googleVolumeListResponse
est de type Object
(ouJavaScript Plain Object).
Cela n'est pas bloquant mais on risque de perdre l'aide du compilateur et commettre des erreurs.
Les méthodes de la classe HttpClient
sont des méthodes génériques et il est donc possible de contrôler leur type de retour.
Ainsi, avec l'exemple ci-dessous :
nous obtenons l'erreur suivante :
error TS2551: Property 'totalItem' does not exist on type 'GoogleVolumeListResponse'. Did you mean 'totalItems'?
ATTENTION ! Le paramètre de type GoogleVolumeListResponse
passé à la méthode n'est qu'un "hint".
Si l'API retourne des données sous une forme différente ou si l'interface GoogleVolumeListResponse
est erronée ou simplement pas à jour, alors la compilation va réussir mais en revanche nous risquons de nous retrouver avec des types incohérents dans nos variables et propriétés (et potentiellement n'importe où dans l'application tant que les données retournées par l'API ne sont pas vérifiées en "runtime").
A titre d'exemple, si l'API renvoie le JSON suivant : {"totalItems": "oups!"}
alors notre propriété bookCount
qui est bien de type number
, contiendra le string oups!
.
Pour éviter les problèmes décrits précédemment, il est préférable d'éviter de se baser uniquement sur le "hint" de type de la réponse et de le propager dans l'application.
Nous allons donc transformer la "response" en une entité associée à notre "feature".
Malheureusement, la classe HttpClient
abuse massivement de l'anti-pattern de "method overloading".
L'anti-pattern est tellement poussé à l'extrême que le type de retour peut changer en fonction de la valeur de certains paramètres (i.e. paramètresobserve
et responseType
).
Si vous disposez d'une spécification OpenAPI (Swagger) de votre API, __pensez à générer ces types avec Swagger Codegen ou directement depuis Swagger Online Editor .
Si vous consommez votre propre API, pensez à profiter du pour construire directement vos entités :