Client HTTP
Je vais d'abord expliquer comment utiliser directement le client Core, puis expliquer l'intégration optionnelle de l'adaptateur HTTP commun utilisé par le service généré automatiquement.
Utilisation directe du client Core.
Les Paths injectés dans createHttpClient<Paths>() sont le contrat de requête. L'URL et la méthode proviennent de la clé de Paths, la queryString et le pathVariable proviennent des paramètres, et le corps est déterminé par requestBody.
Le type de réponse est spécifié par l'appelant dans callApi<R>(). Core ne déduit pas automatiquement le type de réponse à partir des réponses OpenAPI.
httpClient.ts
tsLa forme de la réponse est choisie par API.
typed-rx-http n'impose pas ResponseWrapper. Si la réponse du serveur est un wrapper, spécifiez le type de wrapper comme R, sinon spécifiez simplement le type de réponse réel.
Option : adaptateur commun du projet + service généré automatiquement.
La configuration commonService ci-dessous n'est pas une structure obligatoire de Core, mais un modèle d'intégration de projet visant à appliquer l'authentification, les en-têtes SSR et les politiques de cache à plusieurs services générés en une seule fois.
Ce que fait le commonService du projet.
commonService ne désigne pas un nom de classe spécial fourni par @byeolnaerim/typed-rx-http, mais un fichier appartenant à l'utilisateur utilisé pour regrouper les politiques HTTP communes du projet. Le nom du fichier est libre, et dans l'exemple ci-dessous, nous utilisons le nom de projet réel rxjsHttpService.ts.
L'écran et le service généré automatiquement n'appellent pas createHttpClient plusieurs fois, et ce fichier utilise callApi et callApiStream comme point d'entrée commun. Ainsi, si vous modifiez une fois les règles de renouvellement d'authentification, de transmission d'en-têtes SSR, de cache et de gestion des erreurs, elles s'appliquent à tous les services générés.
Commencez par voir le code complet de commonService/rxjsHttpService.
1. Forme minimale complète
L'essence de commonService est le code ci-dessous. Créez une fois headerStore et un client HTTP typé, puis exportez callApi/callApiStream que le service généré utilisera communément. uploadFile et createSSEObservable peuvent également être exposés de la même manière depuis ce client.
rxjsHttpService.ts
ts2. Next.js + authentification de session + cache CSR/SSR inclus
Voici un exemple de projet complet ajoutant l'authentification de session, l'en-tête SSR et le cache CSR/SSR au même adaptateur public. Si le service généré importe également le wrapper de cache, cette forme devient la référence. Il suffit de copier, puis d'ajuster setLogin import, ApiTypes et CacheNames, le chemin de l'API d'authentification, les variables d'environnement et le chemin non autorisé selon votre projet.
rxjsHttpService.ts
tsRôle par composition de code
paths
C'est le type de chemins OpenAPI utilisé par createHttpClient et ServiceArguments pour vérifier l'URL, la méthode, les variables de chemin, les requêtes et les types de corps.
headerStore
Stocke les en-têtes communs comme Content-Type et Authorization dans le navigateur et les partage avec l'authentification de session et la connexion RSocket.
headersProvider
CSR renvoie headerStore et SSR lit les cookies et l'Authorization de la requête actuelle pour fournir des en-têtes différents à chaque requête.
service
Client HTTP typé réel avec URL de base, en-têtes communs, gestion des erreurs 401 du serveur et message d'erreur par défaut.
sessionAuth
Synchronise le token de session avant la requête et, en cas de 401, réessaye une fois l'Observable d'origine après un rafraîchissement, sinon exécute le flux de déconnexion.
callApi / callApiStream
Fonctions communes importées par le service REST généré automatiquement et le service de flux NDJSON. Les deux renvoient un Observable RxJS.
callApiClientCache / callApiServerCache
Wrapper de cache qui utilise le cache CSR dans le navigateur et charge dynamiquement le cache SSR de @byeolnaerim/typed-rx-http/next sur le serveur.
Méthode de connexion au service généré automatiquement
Le générateur calcule le chemin relatif du commonServiceFile et ajoute l'import à chaque service. L'écran n'appelle pas directement le fichier commun, mais importe la fonction générée, qui transforme le chemin, les paramètres et le corps en pathVariable, queryString et body de ServiceArguments pour les transmettre à callApi.
generateSwagger.cjs
jsUne seule réponse est firstValueFrom.
Les API REST qui répondent une fois et se terminent, comme la recherche, l'enregistrement et la suppression, peuvent êtrefirstValueFromutilisées naturellement même dans des fonctions async existantes.
BusinessSearchPage.tsx
tsxÀ l'écran, paramsseulementtransmis sous la forme { params: { ... } }.est visible, mais le service généré contient l'URL, la méthode HTTP et le type de réponse. Les paramètres de requête sont toujours
Plusieurs réponses sont abonnées
Les requêtes avec plusieurs valeurs, comme la progression des tâches ou le flux RSocket, arriventsubscribeet se désabonnent lorsque le composant disparaît.
BatchJobPage.tsx
tsxLorsque vous utilisez directement callApi
Pour les projets ne utilisant pas le générateur de service ou pour vérifier un point de terminaison temporaire avant la génération, vous pouvez appeler directement callApi du service commun. Le type de requête est vérifié dans les chemins et le type de réponse est spécifié par le demandeur en générique.