[Partie 1] Description de l'API d'un produit existant au format OpenAPI

Chapitre 1 : Introduction aux API et à OpenAPI
__1.1 Qu'est-ce que l'écosystème API ?
1.2 Description de l'API
____1.2.1 Le travail de Bridget
____1.2.2 Le potentiel de la solution de Bridget
__1.3 Qu'est-ce qu'OpenAPI ?
____1.3.1 Exemple de définition OpenAPI
__1.4 Où est-il préférable d'utiliser la définition OpenAPI ?
__1.5 Qu'est-ce que Swagger ?
__1.6 Qu'est-ce que le REST ?
__1.7 Quand utiliser OpenAPI ?
____1.7.1 Utilisateurs de l'API
____1.7.2 Fournisseur d'API
____1.7.3 Concepteur d'API
1.8 Structure de ce livre
__1.9 Résumé

Chapitre 2 : Préparation des requêtes API
2.1 Définition du problème
____2.1.1 Présentation de l'API de vente directe
____2.1.2 Les deux premières opérations de l'API de vente directe
__2.2 Préparation du facteur
__2.3 API de vente directe
__2.4 Voir la liste des avis
____2.4.1 Configuration d'une requête GET
____2.4.2 Vérification
2,5 Laissez un avis
____2.5.1 Configuration d'une requête POST
____2.5.2 Vérification
__2.6 Pratique
____2.6.1 L'API La Vérité sur les Chats
____2.6.2 API d'avatar minimale
____2.6.3 API du moteur de recherche DuckDuckGo
____2.6.4 API d'argot pirate
__2.7 HTTP pour les guerriers
__2.8 Résumé

Chapitre 3 : Premières impressions sur la définition d’OpenAPI
3.1 Définition du problème
3.2 Introduction à la spécification OpenAPI
3.3 Aperçu de YAML
___3.3.1 Conversion de JSON en YAML
3.4 Description de l'opération GET
__3.5 Extension de l'opération GET
__3.6 Résumé

Chapitre 4 : Création d’une définition OpenAPI avec l’éditeur Swagger
4.1 Présentation de l'éditeur Swagger
___4.1.1 Panneau de l'éditeur
___4.1.2 Panneau de documentation de l'interface utilisateur
___4.1.3 Menu Outils
___4.1.4 Sauvegarde
4.2 Création d'une définition OpenAPI dans l'éditeur Swagger
___4.2.1 Définition Mini OpenAPI valide
4.2.2 Création d'une définition OpenAPI dans l'éditeur Swagger
___4.2.3 Vérification
__4.3 Ajout de la requête GET /reviews
__4.4 Appels API
___4.4.1 Appel de la requête GET /reviews
___4.4.2 Ajout d'informations serveur à la définition OpenAPI
4.4.3 Appelez à nouveau GET /reviews
__4.5 Résumé

Chapitre 5 : Description des réponses de l’API
__5.1 Réponse HTTP
5.2 Définition du problème
__5.3 Le monde fascinant des schémas de données
__5.4 Schéma JSON
___5.4.1 champ de type
___5.4.2 Ajout de champs à un objet
___5.4.3 minimum et maximum
___5.4.4 Nombres et entiers
__5.5 Code d'état
__5.6 Type de média (MIME)
5.7 Description de la réponse GET /reviews
___5.7.1 Réponse Super Mini
___5.7.2 GET /reviews 200 Corps de réponse
5.7.3 Ajouter un champ d'évaluation au corps de la réponse
___5.7.4 Ajouter les champs message, uuid et userId
__5.8 Résumé

Chapitre 6 : Création de ressources
6.1 Définition du problème
6.2 Description de la requête POST /reviews et du corps de la requête
___6.2.1 Corps de la requête
6.2.2 Schéma du corps de la requête
6.3 Créer un nouvel avis
6.3.1 Fonctionnalité d'essai améliorée avec des exemples supplémentaires
6.4 Description de la requête GET /reviews/{reviewId} avec les paramètres de chemin
___6.4.1 Paramètres de chemin
___6.4.2 Description du paramètre de chemin reviewId
6.5 Confirmer la création de l'avis
__6.6 Résumé

Chapitre 7 Authentification et autorisation
7.1 Définition du problème
7.2 Préparation à la certification
___7.2.1 Défi : Rédiger une requête POST /users
___7.2.2 Défi : Écrire une requête POST /tokens
7.2.3 Solution : Modifier la définition
7.2.4 Vérifier les capacités de création d'utilisateurs et de jetons
7.3 Ajout de l'en-tête d'autorisation
___7.3.1 Méthode de traitement des autorisations OpenAPI
___7.3.2 Méthodes d'autorisation (sécurité) prises en charge par OpenAPI 3.0.x
7.3.3 Ajout d'un en-tête d'autorisation au schéma de sécurité
___7.3.4 Ajouter des exigences de sécurité à la requête POST /reviews
7.3.5 Vérification du fonctionnement de la fonction de sécurité
7.4 Appliquer éventuellement des mesures de sécurité
7.5 Autres systèmes de sécurité
7.6 Méthodes générales d'application des schémas de sécurité
__7.7 Résumé

Chapitre 8 : Préparation et hébergement de la documentation API
8.1 Définition du problème
8.2 Ajout de métadonnées à la définition de l'API
8.3 Rédiger des descriptions en Markdown
___8.3.1 Principes de base de Markdown
8.3.2 Ajout d'une description Markdown à la définition de l'API de vente directe
8.4 Opérations de regroupement avec des balises
8.4.1 Ajout de balises à l'opération GET /reviews
8.4.2 Ajouter une description à la balise
8.4.3 Ajout d'étiquettes aux opérations restantes
__8.5 Documentation de l'API d'hébergement avec Netlify.com et Swagger UI
___8.5.1 Préparation de l'interface utilisateur Swagger avec la définition OpenAPI
___8.5.2 Hébergé par Netlify.com
__8.6 Partie 1 Conclusion
__8.7 Résumé

[Partie 2] Conception d'API : OpenAPI et Swagger

Chapitre 9 : Conception d'applications Web
__9.1 Idées de garde d'animaux
Lancement du projet de gardiennage d'animaux de compagnie __9.2
___9.2.1 Exigences supplémentaires
___9.2.2 Structure de l'équipe
___9.2.3 Architecture centrée sur les API
Plan ___9.2.4
9.3 Modélisation du domaine et API
___9.3.1 Modélisation du domaine pour l'utilisation des API
___9.3.2 Examen de l'API de vente directe
__9.4 Modèle de domaine pour les gardiens d'animaux
___9.4.1 Concepts utilisés dans le modèle
___9.4.2 Modèle utilisateur
___9.4.3 Offres d'emploi et animaux modèles
__9.5 Témoignage d'utilisateur de Pet Sitter
___9.5.1 Qu'est-ce qu'une User Story ?
___9.5.2 Collecte des témoignages utilisateurs
___9.5.3 Cartographie des récits utilisateurs
__9.6 Résumé

Chapitre 10 : Conception d’API avec OpenAPI
__10.1 Problème
___10.1.1 Conversion du modèle de domaine en OpenAPI
___10.1.2 Garantir la réutilisabilité
__10.2 Création d'un schéma
___10.2.1 Fichier OpenAPI contenant le schéma
___10.2.2 Référence de schéma commun
___10.2.3 Schéma utilisateur
___10.2.4 Schéma de poste
___10.2.5 Schéma du chien
___10.2.6 Schéma de candidature
10.3 Opérations API et CRUD
___10.3.1 Définition des requêtes et réponses API
___10.3.2 Histoires d'utilisateurs et conception CRUD
API Pet Sitter __10.4
___10.4.1 Opérations requises pour le schéma utilisateur
___10.4.2 Opérations requises pour le schéma de travail
___10.4.3 Opérations requises pour le schéma JobApplication
__10.5 Résumé

Chapitre 11 : Création d’un flux de travail de gestion des changements avec une approche axée sur la conception d’API
__11.1 Problème
__11.2 Discussion et réponse sur le changement
__11.3 GitHub comme moteur de workflow
___11.3.1 Source unique de vérité
___11.3.2 Proposition de modification
___11.3.3 Acceptation des modifications
___11.3.4 Comparaison des modifications
__11.4 Intégration du flux de travail GitHub
___11.4.1 Configuration de GitHub et de la source de vérité
___11.4.2 Étapes du flux de travail GitHub
__11.5 Exercices pratiques sur le flux de travail
___11.5.1 Suggestion ajoutée pour SUPPRIMER /jobs/{id}
___11.5.2 Examiner et accepter les modifications
___11.5.3 Comparaison des anciennes et des nouvelles branches
___11.5.4 Ce que nous avons fait au chapitre 11
__11.6 Résumé

Chapitre 12 : Implémentation du code front-end et gestion des changements
__12.1 Problème
__12.2 Configuration du serveur Prism Neck
___12.2.1 Installation de Prism
___12.2.2 Vérification du fonctionnement du prisme
__12.3 Développement front-end basé sur le serveur Wooden
___12.3.1 Ajout d'exemples à la définition OpenAPI
___12.3.2 Application d'exemples aux prismes
__12.4 Identification des opérations API manquantes
___12.4.1 Révision de l'ajout de nouvelles opérations
___12.4.2 Nouvelle conception opérationnelle
___12.4.3 Sélection des données du col à renvoyer par le prisme
___12.4.4 Proposition de modification
___12.4.5 Exemple curl
__12.5 Résumé

Chapitre 13 : Création d’un backend avec Node.js et Swagger CodeGen
__13.1 Problème
__13.2 Présentation de Swagger Codegen
___13.2.1 Génération du code client
___13.2.2 Génération du code serveur
___13.2.3 Générateur Swagger
__13.3 Structure du backend
___13.3.1 Génération du code backend
___13.3.2 Analyse de la structure du backend
___13.3.3 Modifications de l'API ouverte
__13.4 Modification de l'API OpenAPI du backend
___13.4.1 Ajouter l'ID d'opération
___13.4.2 Opérations de l'API de balisage
___13.4.3 Régénération des stubs du backend
__13.5 Exécution et test du code backend
___13.5.1 Tests avec Postman
___13.5.2 Test de validation des entrées
___13.5.3 Vérification des résultats à l'aide d'un prisme
__13.6 Sauvegarde d'une base de données avec Mongoose
___13.6.1 Corrections de l'API
___13.6.2 Préparation à l'utilisation de MongoDB
___13.6.3 Configuration de Mongoose
___13.6.4 Création d'un modèle
__13.7 Implémentation des méthodes API
__13.8 Résumé

Chapitre 14 : Intégration et déploiement d’applications Web
__14.1 Problème
___14.1.1 Authentification
___14.1.2 Organisation du code
___14.1.3 Fournir conjointement les composants backend et frontend
__14.2 Mise en œuvre de l'autorisation
___14.2.1 Création d'un système de sécurité
___14.2.2 Ajout de l'action « Connexion »
___14.2.3 Définition de la sécurité opérationnelle
14.3 Gestion du référentiel
___14.3.1 Maintien de la structure existante
___14.3.2 Utilisation d'un dépôt Git partagé
___14.3.3 Consolidation du code et des définitions d'API dans un seul dépôt
___14.3.4 Décisions et refactorisation
__14.4 Configuration du serveur Web intégré
___14.4.1 Conception d'URL
___14.4.2 Configuration du serveur
__14.5 Résumé

[Partie 3] Extension et évolution de l'API après le lancement du produit

Chapitre 15 : Conception d’API secondaires
__15.1 Revue du premier sprint de développement
__15.2 Planification du prochain sprint
__15.3 Préparation de nouvelles fonctionnalités
___15.3.1 Réexamen du modèle de domaine
___15.3.2 Analyse des récits utilisateurs
__15.4 Améliorations de l'expérience développeur
___15.4.1 Cohérence
___15.4.2 Gestion des erreurs
___15.4.3 Validation des entrées
___15.4.4 Gestion des versions et évolution
__15.5 Résumé

Chapitre 16 : Conception de schémas à l’aide de la composition OpenAPI
__16.1 Problème
__16.2 Polymorphisme et héritage du modèle de domaine
__16.3 Mise à jour du schéma
___16.3.1 Schéma de l'animal de compagnie
___16.3.2 Schéma du chien
___16.3.3 Schéma du chat
__16.4 Polymorphisme et héritage dans OpenAPI
___16.4.1 Composition au sein des schémas du chien et du chat
___16.4.2 Composition au sein du schéma Pet
__16.5 Ajouter un délimiteur OpenAPI
__16.6 Résumé

Chapitre 17 : Application des filtres et de la pagination aux points de terminaison de la collection
__17.1 Problème
__17.2 Conception du filtrage
___17.2.1 Filtre de projection
___17.2.2 Filtre de sélection
___17.2.3 Gestion des schémas imbriqués
___17.2.4 Langage de requête
___17.2.5 Pratiques particulières
__17.3 Filtrage des gardiens d'animaux
___17.3.1 Sélection du champ des critères de filtrage
___17.3.2 Application du filtrage à OpenAPI
___17.3.3 Demande d'inclusion de filtres
__17.4 Conception de la pagination
___17.4.1 Pagination par décalage et par page
___17.4.2 Pagination basée sur le curseur
__17.5 Application du système de radiomessagerie aux gardiens d'animaux
___17.5.1 Application de la pagination à OpenAPI
___17.5.2 Exemple d'extension de la requête
__17.6 Conception du tri
___17.6.1 Tri par champ unique
___17.6.2 Tri multi-champs
___17.6.3 Cohérence du type de paramètre
__17.7 Application du tri aux gardiens d'animaux
___17.7.1 Champs de tri
___17.7.2 Conception des paramètres de tri
___17.7.3 Ajouter une fonctionnalité de tri à la définition OpenAPI
___17.7.4 Exemple de requête avec filtrage, pagination et tri
__17.8 Résumé

Chapitre 18 : Gestion des exceptions avec Problem+Json
__18.1 Définition du problème
__18.2 Classification des erreurs
___18.2.1 Détection des situations de défaillance
___18.2.2 Modèles d'erreurs courants
__18.3 Exigences relatives aux réponses aux erreurs
__18.4 Format de l'outil OAS
__18.5 problème+format json
__18.6 Ajout de réponses d'erreur à la définition OpenAPI
___18.6.1 Création d'un schéma d'erreur
___18.6.2 Ajouter une réponse d'erreur aux opérations
__18.7 Guide de gestion des erreurs
___18.7.1 Développement front-end
___18.7.2 Développement backend
__18.8 Résumé

Chapitre 19 : Validation des entrées à l’aide d’un schéma JSON avancé
__19.1 Définition du problème
__19.2 Détails de validation
___19.2.1 Propriétés readOnly, writeOnly
___19.2.2 Application des contraintes numériques
___19.2.3 Conversion de format de chaîne
___19.2.4 Application des contraintes de tableau
___19.2.5 Définition de l'énumération
___19.2.6 Liste des propriétés obligatoires et facultatives
___19.2.7 Spécification des valeurs par défaut
Mise à jour du programme de garde d'animaux de compagnie __19.3
___19.3.1 Schéma utilisateur
___19.3.2 Schéma de poste
___19.3.3 Schéma de candidature
___19.3.4 Schéma Animal de compagnie, Chien, Chat
__19.4 Résumé

Chapitre 20 : Gestion des versions d’API et traitement des changements majeurs
__20.1 Définition du problème
__20.2 Qu'est-ce qu'un changement majeur ?
__20.3 Modifications majeures publiées
___20.3.1 Coordination du changement au sein de l'entreprise
___20.3.2 Gestion des versions de l'API
___20.3.3 Distinguer les versions de schéma à l'aide des types de médias
___20.3.4 Avis concernant les fonctionnalités ajoutées/supprimées
__20.4 Résumé

Chapitre 21 : Liste de vérification avant le lancement de l’API
__21.1 Avantages et inconvénients des API publiques
Liste de contrôle __21.2
__21.3 Fonctionnement normal de l'API
___21.3.1 Tests unitaires de l'API
___21.3.2 Tests de bout en bout
__21.4 Documentation
__21.5 Garantir la cohérence de l'API
__21.6 Validation et signalement des erreurs
Feuille de route et index de l'API __21.7 publiés
__21.8 Stratégie de changement
__21.9 Améliorations de la sécurité
Surveillance de l'API __21.10
___21.10.1 Configuration de la collecte d'indicateurs
Version API 21.11
Résumé du 21.12

Annexe A Swagger 2.0, OpenAPI 3.0, OpenAPI 3.1
Annexe B [Annexe spéciale coréenne] Comment utiliser Swagger dans les services Web Spring Boot

Ce que ce livre couvre

Ce livre explique comment décrire et concevoir des API.
Ce guide d'introduction au monde d'OpenAPI explore les outils et les pratiques utilisés par les développeurs d'API qui appliquent les principes de conception axée sur le design.
Il commence par les bases de la lecture et de l'écriture des définitions OpenAPI, puis aborde la conception de domaine, les modifications de flux de travail et les modèles de conception d'API.
Bien que nous nous concentrions sur OpenAPI et la conception d'API, nous avons essayé de couvrir des sujets couvrant l'ensemble du cycle de vie des API, tant du point de vue technique que de celui de la gestion de projet.
J'espère que ce livre vous aidera à comprendre et à prendre confiance dans les problèmes que résout OpenAPI, dans sa raison d'être et dans son utilisation.

- Décrire l'API d'un produit existant au format OpenAPI.
- Appliquer une approche axée sur la conception à la conception d'API en utilisant OpenAPI et Swagger.
- Découvrez comment développer et faire évoluer votre API après le lancement du produit.
- Apprendre la syntaxe et la structure d'OpenAPI.
- Créer une définition OpenAPI à l'aide de Swagger.
- Automatiser les processus et générer automatiquement du code.
- Apprenez à collaborer entre les différentes fonctions de l'organisation.

Public cible de ce livre

Cet ouvrage est une lecture incontournable pour les développeurs de logiciels qui s'intéressent aux API et souhaitent les utiliser en privilégiant la conception.
Un ouvrage incontournable pour tous ceux qui doivent prendre des décisions relatives aux API : développeurs front-end ou back-end, chefs de produit, testeurs QA et même PDG.
Nous avons veillé à rendre le livre accessible même si vous n'avez pas une connaissance approfondie d'un sujet particulier, et si vous êtes familier avec des concepts comme JSON ou HTTP, vous ne devriez avoir aucun mal à suivre le livre.
Il comprend également de nombreux avis simples et des liens vers des ressources externes.

Structure de ce livre

[Partie 1] Description de l'API d'un produit existant au format OpenAPI
Chapitre 1 : Signification et méthode de description des API
Chapitre 2 : Postman, un outil utilisé pour explorer les API
Chapitre 3 : Comment décrire une API Farmstall préconfigurée
Chapitre 4 : Comment utiliser l’éditeur Swagger
Chapitre 5 : Description des requêtes et réponses API de base
Chapitre 6 : Organismes de demande et de réponse
Chapitre 7 : Comprendre l’authentification et l’autorisation
Chapitre 8 : Comment héberger un site web fournissant de la documentation API à l’aide de Swagger UI

[Partie 2] Concevoir une API à partir de zéro avec OpenAPI et Swagger
Chapitre 9 : Présentation du projet PetSitter, qui sera abordé tout au long de la partie 2.
Chapitre 10 : Concevoir une API et la décrire à l’aide d’OpenAPI
Chapitre 11 : Présentation d’un flux de travail basé sur Git pour la gestion des modifications de conception d’API
Chapitre 12 : Comment simuler votre API et réagir aux changements du point de vue d’un utilisateur d’API
Chapitre 13 : Implémentation d’une API à l’aide de Swagger CodeGen
Chapitre 14 : Préparation à l’utilisation de l’API et intégration du frontend et du backend

[Partie 3] Extension et évolution de la conception de l'API créée dans la partie 2
Chapitre 15 : Planification des prochaines étapes de votre itération d’API
Chapitre 16 : Extension du modèle de domaine à l’aide de la composition de schémas JSON
Chapitre 17 : Ajout du filtrage, de la pagination et du tri à votre API
Chapitre 18 : Comprendre le problème et le format de réponse JSON, et appliquer la gestion des erreurs aux API
Chapitre 19 : Extension du schéma JSON et application de la validation des entrées
Chapitre 20 : Gestion des versions d’API et des changements incompatibles
Chapitre 21 : Liste de vérification de la version finale de l’API

[Annexe] Différences entre Swagger 2.0, OpenAPI 3.0 et OpenAPI 3.1
[Annexe spéciale de l'édition coréenne] Comment utiliser Swagger dans les services Web Spring Boot

Note de l'auteur

Swagger, une suite d'outils conçue pour vous aider à définir et à rédiger la documentation d'une API REST, vous permet de fournir une documentation API hautement utilisable et sécurisée.
Swagger implémente la spécification OpenAPI, une norme indépendante de toute entreprise spécifique. Ainsi, lorsque vous utilisez Swagger, vous utilisez les mêmes normes acceptées par Google, Microsoft et Amazon.
Ce livre présente une approche axée sur la conception. Les développeurs débutants en conception d'API peuvent y apprendre l'intégralité du cycle de vie d'une API, de la conceptualisation à la mise en production.
Au fur et à mesure que vous réaliserez les exemples, vous apprendrez les bonnes pratiques et les erreurs à éviter en matière de conception et de développement d'API.
Acquérir une expérience pratique en concevant des API qui répondent aux besoins de votre entreprise à l'aide d'outils qui génèrent automatiquement la documentation et des maquettes ou des SDK clients conviviaux pour les développeurs.
Même si vous êtes un développeur web sans aucune connaissance préalable de Swagger ou d'OpenAPI, vous pouvez facilement lire ceci.

Note du traducteur

Je me souviens qu'à l'époque où Internet a fait son apparition, il existait un contenu de divertissement expérimental qui testait dans quelle mesure on pouvait se débrouiller uniquement grâce à Internet, sans quitter son domicile.
Mais maintenant, je ne pense pas que quiconque regardera ce genre de divertissement.
Car nous savons tous que toute personne ayant accès à un smartphone peut mener une vie confortable en utilisant uniquement Internet.
Si l'on continue d'explorer ce monde pratique, où l'on peut recevoir et utiliser des objets, se faire livrer des repas et même s'en vanter sur les réseaux sociaux en quelques clics, on découvre des API omniprésentes. Ces API servent de points de connexion entre différents logiciels, assurant ainsi la solidité de cet univers.

Les API, qui servent de point de connexion pour les logiciels, constituent un moyen de communication pour les développeurs de logiciels.
Pour garantir une communication fluide, nous devons créer un cahier des charges qui définit le format des données à échanger et la méthode d'appel, accompagné d'une description conviviale.
Autrement dit, vous devez décrire l'API.
OpenAPI est une spécification standard qui décrit les API HTTP basées sur le protocole HTTP. Les standards permettant l'automatisation, de nombreuses tâches peuvent être automatisées grâce à OpenAPI.
Ce livre explique comment décrire les définitions d'API à l'aide d'OpenAPI.
Si cela s'était arrêté là, le livre aurait pu être ennuyeux, mais il couvre tout, depuis l'organisation des exigences d'un petit service web, la rédaction de récits utilisateurs, la conception d'un modèle de domaine métier basé sur ces récits, la conception d'une API qui les reflète, la rédaction d'une définition d'API à l'aide d'OpenAPI, l'augmentation de la productivité du développement grâce à l'automatisation basée sur la définition, et même la manière de faire évoluer et d'étendre l'API en douceur au fil du temps.

Lors de la conception d'API, il arrive fréquemment que l'on conçoive et implémente ces dernières par simple commodité, sans formation ni respect des normes, ce qui complique leur extension ultérieure. En revanche, la lecture des bonnes pratiques présentées dans cet ouvrage vous permettra d'acquérir naturellement les connaissances nécessaires à la conception d'API évolutives. Ce contenu serait déjà précieux en soi, mais le processus est en outre présenté de manière ludique, comme la formation d'une petite équipe projet où chacun joue son rôle, rencontre et résout les difficultés, loin des explications rigides et ennuyeuses. Cette approche rend l'apprentissage passionnant et même agréable.
De plus, bien qu'il utilise parfois des technologies spécifiques à titre d'exemples, il n'est pas intrinsèquement dépendant d'outils particuliers, ce qui en fait un ouvrage intéressant et utile pour tous les développeurs qui créent et utilisent des API.

Le contenu de ce livre décrit généralement le processus de conception et de création d'un nouveau système à l'aide d'OpenAPI. Vous pourriez donc vous demander si ce processus n'est pas applicable aux systèmes existants. Heureusement, il existe une méthode pour l'appliquer également aux systèmes existants.
Si vous utilisez un serveur API basé sur Spring Boot, qui est la plateforme de développement de serveurs API la plus utilisée en Corée, vous pouvez créer automatiquement un site Swagger UI avec seulement quelques paramètres et annotations simples.
Bien qu'il s'agisse d'un exemple simple, j'ai pensé qu'il serait assez utile en pratique, je l'ai donc ajouté en annexe spéciale à la version coréenne.

Tout comme pour le codage, je vois toujours des marges de progression en traduction.
Il en serait probablement de même pour les auteurs qui ont écrit le livre original.
Le travail principal d'un traducteur est de traduire le texte original en coréen, mais je crois qu'un excellent traducteur est quelqu'un qui, d'abord, lit le texte original du point de vue du lecteur, repère les points problématiques, les améliore et présente finalement un meilleur résultat au lecteur.
Cette fois encore, il y aura peut-être des imperfections, mais je voulais au moins imiter l'excellent traducteur, alors j'ai travaillé sur la traduction dans le but de la rendre meilleure que l'originale.
J’espère sincèrement que les lecteurs pourront lire ce livre avec autant d’aisance que s’il avait été écrit en coréen dès le départ.