Merge branch 'master' of https://github.com/madeindjs/api_on_rails

Author: madeindjs

fr/00_before.adoc

@@ -9,9 +9,9 @@ L’œuvre originale étant non maintenue, j’ai voulu mettre à jour cet excel
 
 https://twitter.com/kurenn[Abraham Kuri] est un développeur Rails avec 5 ans d’expérience (sûrement plus maintenant). Son expérience inclut le travail en tant que _freelance_ dans la construction de produits logiciels et plus récemment dans la collaboration au sein de la communauté open source. Diplômé en informatique d’ITESM, il a fondé deux sociétés au Mexique (http://icalialabs.com/[Icalia Labs] et http://codeandomexico.org/[Codeando Mexico]).
 
-De mon côté, je m’appelle http://rousseau-alexandre.fr[Alexandre Rousseau] et je suis un développeur Rails avec plus de 4 ans d’expérience (à l’heure ou j’écris ces lignes). Je suis actuellement associé dans une entreprise (https://isignif.fr[iSignif]) ou je construit et maintient un produit de type SAAS en utilisant Rails. Je contribue aussi à la communauté Ruby en produisant et maintenant quelques gemmes que vous pouvez consulter sur https://rubygems.org/profiles/madeindjs[mon profil Rubygems.org]. La plupart de mes projets sont sur Github donc http://github.com/madeindjs/[n’hésitez pas à me suivre].
+De mon côté, je m’appelle http://rousseau-alexandre.fr[Alexandre Rousseau] et je suis un développeur Rails avec plus de 4 ans d’expérience (à l’heure où j’écris ces lignes). Je suis actuellement associé dans une entreprise (https://isignif.fr[iSignif]) ou je construis et maintiens un produit de type SAAS en utilisant Rails. Je contribue aussi à la communauté Ruby en produisant et maintenant quelques gemmes que vous pouvez consulter sur https://rubygems.org/profiles/madeindjs[mon profil Rubygems.org]. La plupart de mes projets sont sur Github donc http://github.com/madeindjs/[n’hésitez pas à me suivre].
 
-Tout le code source de ce livre est disponible au format https://asciidoctor.org[Asciidoctor] sur https://github.com/madeindjs/api_on_rails[Github]. Ainsi n’hesitez pas à https://github.com/madeindjs/api_on_rails/fork[forker] le projet si vous voulez l’améliorer ou corrigé une faute qui m’aurais échappé.
+Tout le code source de ce livre est disponible au format https://asciidoctor.org[Asciidoctor] sur https://github.com/madeindjs/api_on_rails[Github]. Ainsi n’hésitez pas à https://github.com/madeindjs/api_on_rails/fork[forker] le projet si vous voulez l’améliorer ou corriger une faute qui m’aurait échappée.
 
 === Droits d’auteur et licence
 

fr/04_refactoring_tests.adoc

@@ -124,10 +124,10 @@ RSpec.describe Api::V1::UsersController, type: :controller do
 end
 ----
 
-Comme vous pouvez le voir, il y a beaucoup de code dupliqué. Deux possibilité de factorisation sont:
+Comme vous pouvez le voir, il y a beaucoup de code dupliqué. Les deux possibilités de factorisations sont:
 
-* La méthode `JSON.parse` peut être encapsulée sur une méthode.
-* Le paramètre format est envoyé à chaque demande. Bien que ce ne soit pas une mauvaise pratique, il est préférable de gérer le type de réponse à l’aide des en-têtes.
+* La méthode `JSON.parse` qui peut être encapsulée sur une méthode.
+* Le paramètre format qui est envoyé à chaque demande. Bien que ce ne soit pas une mauvaise pratique, il est préférable de gérer le type de réponse à l’aide des en-têtes.
 
 Ajoutons donc une méthode pour gérer la réponse JSON. Mais avant de continuer, et si vous avez suivi le tutoriel, vous savez peut-être que nous créons une branche pour chaque chapitre. Alors faisons-le:
 
@@ -193,7 +193,7 @@ end
 
 RSpec.configure do |config|
   #  ...
-  # Nous devons aussi inclure ces methodes dans rspec en tant
+  # Nous devons aussi inclure ces méthodes dans rspec en tant
   # qu'aides de type controleur
   config.include Request::JsonHelpers, :type => :controller
   #  ...
@@ -210,7 +210,7 @@ $ git commit -m "Refactors the json parse method"
 
 === Factoriser le paramètre du format
 
-Nous voulons supprimer les paramètres `format: :json` envoyé sur chaque requête. Pour le faire c’est extrêmement facile. Il suffit simplement d’ajouter une ligne à notre fichier `users_controller_spec.rb`:
+Nous voulons supprimer les paramètres `format: :json` envoyés sur chaque requête. Pour le faire c’est extrêmement facile. Il suffit simplement d’ajouter une ligne à notre fichier `users_controller_spec.rb`:
 
 [source,ruby]
 .spec/controllers/api/v1/users_controller_spec.rb
@@ -219,7 +219,7 @@ RSpec.describe Api::V1::UsersController, type: :controller do
   before(:each) { request.headers['Accept'] = "application/vnd.marketplace.v1, application/json" }
 ----
 
-En ajoutant cette ligne, vous pouvez maintenant supprimer tous les paramètres de `format` que nous envoyions sur chaque requête!
+En ajoutant cette ligne, vous pouvez maintenant supprimer tous les paramètres de `format` que nous envoyons sur chaque requête!
 
 Attendez, ce n’est pas encore fini! Nous pouvons ajouter un autre en-tête à notre demande qui nous aidera à décrire les données que nous attendons du serveur à livrer. Nous pouvons y parvenir assez facilement en ajoutant une ligne supplémentaire spécifiant l’en-tête `Content-Type`:
 

fr/05_athentification.adoc

@@ -218,7 +218,7 @@ $ mv app/controllers/sessions_controller.rb app/controllers/api/v1
 $ mv spec/controllers/sessions_controller_spec.rb spec/controllers/api/v1
 ----
 
-Après avoir déplacé les fichiers, nous devons les mettre à jour pour qu’ils correspondent à la structure des répertoires que nous avons actuellement. Comme le montrent les listing suivants.
+Après avoir déplacé les fichiers, nous devons les mettre à jour pour qu’ils correspondent à la structure des répertoires que nous avons actuellement, comme le montrent les listing suivants.
 
 [source,ruby]
 .app/controllers/api/v1/sessions_controller.rb
@@ -403,11 +403,11 @@ $ git commit -m "Adds destroy session action added"
 
 Si vous avez déjà travaillé avec https://github.com/plataformatec/devise[devise], vous connaissez sûrement déjà les méthodes générées pour gérer l’authentification ou bien pour obtenir l’utilisateur connecté (voir la https://github.com/plataformatec/devise#getting-started[documentation]).
 
-Dans notre cas, nous allons remplacer la méthode `current_user` pour répondre à nos besoins. C’est-à-dire retrouver l’utilisateur grâce à son jeton d’authentification qui envoyé sur chaque requête. Laissez moi clarifier ce point.
+Dans notre cas, nous allons remplacer la méthode `current_user` pour répondre à nos besoins. C’est-à-dire retrouver l’utilisateur grâce à son jeton d’authentification qui est envoyé sur chaque requête. Laissez moi clarifier ce point.
 
 Une fois que le client se connecte, l’API lui retourne son jeton d’authentification. A chaque fois que ce client demande une page protégée, nous devrons retrouver l’utilisateur à partir de ce jeton d’authentification que l’utilisateur aura passé en paramètre ou dans l’en-tête HTTP.
 
-Dans notre cas, nous utiliserons l’en-tête HTTP `Authorization` qui est souvent utilisé pour ça. Personnellement, je le trouve que c’est la meilleur manière parce que cela donne un contexte à la requête sans polluer l’URL avec des paramètres supplémentaires.
+Dans notre cas, nous utiliserons l’en-tête HTTP `Authorization` qui est souvent utilisé pour ça. Personnellement, je le trouve que c’est la meilleure manière parce que cela donne un contexte à la requête sans polluer l’URL avec des paramètres supplémentaires.
 
 Quand il s’agit de l’authentification, j’aime ajouter toutes les méthodes associées dans un fichier séparé. Il suffit ensuite d’inclure le fichier dans le `ApplicationController`. De cette façon, il est très facile à tester de manière isolée. Créons-donc le fichier dans le répertoire `controllers/concerns`:
 
@@ -424,7 +424,7 @@ $ mkdir spec/controllers/concerns
 $ touch spec/controllers/concerns/authenticable_spec.rb
 ----
 
-Comme d’habitude, nous commençons par écrire nos tests. Dans ce cas, notre méthode `current_user`, va chercher un utilisateur par le jeton d’authentification dans l’en-tête HTTP `Authorization`.
+Comme d’habitude, nous commençons par écrire nos tests. Dans ce cas, notre méthode `current_user` va chercher un utilisateur par le jeton d’authentification dans l’en-tête HTTP `Authorization`.
 
 [source,ruby]
 .spec/controllers/concerns/authenticable_spec.rb
@@ -557,7 +557,7 @@ $ git commit -m "Adds the authenticate with token method to handle access to act
 
 === Autoriser les actions
 
-Il est maintenant temps de mettre à jour notre fichier `users_controller.rb` pour refuser l’accès à certaines actions. Nous allons aussi implémenter la méthode `current_user` sur l’action `update` et `destroy` afin de s’assurer que l’utilisateur qui est connecté ne sera capable que de mettre à jour que ses données et qu’il ne pourra supprimer que (et uniquement) son compte.
+Il est maintenant temps de mettre à jour notre fichier `users_controller.rb` pour refuser l’accès à certaines actions. Nous allons aussi implémenter la méthode `current_user` sur l’action `update` et `destroy` afin de s’assurer que l’utilisateur qui est connecté ne sera capable de mettre à jour que ses données et qu’il ne pourra supprimer que (et uniquement) son compte.
 
 Nous allons commencer par l’action `update`. Nous n’irons plus chercher l’utilisateur par son identifiant mais par l’ `auth_token` sur l’en-tête `Authorization` fourni par la méthode `current_user`.
 
@@ -643,7 +643,7 @@ module Request
 end
 ----
 
-Maintenant, chaque fois que nous avons besoin d’avoir l’utilisateur courant sur nos tests, nous appelons simplement la méthode `api_authorization_header`. Je vous laisse le faire avec `users_controller_spec.rb` pour la spécification de mise à jour:
+Maintenant, chaque fois que nous avons besoin d’avoir l’utilisateur courant sur nos tests, nous appelons simplement la méthode `api_authorization_header`. Je vous laisse le faire avec `users_controller_spec.rb` pour le test de mise à jour ?:
 
 [source,ruby]
 .spec/controllers/api/v1/users_controller_spec.rb
@@ -689,7 +689,7 @@ class Api::V1::UsersController < ApplicationController
 end
 ----
 
-Maintenant, pour le fichier de spécification et comme mentionné précédemment, nous avons juste besoin d’ajouter l’en-tête `api_authorization_header`:
+Maintenant, pour le fichier de spécification, et comme mentionné précédemment, nous avons juste besoin d’ajouter l’en-tête `api_authorization_header`:
 
 [source,ruby]
 .spec/controllers/api/v1/users_controller_spec.rb
@@ -709,7 +709,7 @@ RSpec.describe Api::V1::UsersController, type: :controller do
 end
 ----
 
-Tout nos tests devraient passer. La dernière étape de cette section consiste à ajouter les droits d’accès correspondants pour ces deux dernières actions.
+Tous nos tests devraient passer. La dernière étape de cette section consiste à ajouter les droits d’accès correspondants pour ces deux dernières actions.
 
 Il est courant de simplement empêcher les actions sur lesquelles l’utilisateur effectue des actions sur le modèle lui-même. Dans ce cas l’action `update` et `destroy`.
 
@@ -765,7 +765,7 @@ RSpec.describe Authenticable do
 end
 ----
 
-Comme vous pouvez le voir, nous avons ajouté deux simples tests pour savoir si l’utilisateur est connecté ou non. Et comme je l’ai déjà dis, c’est juste pour la clarté visuelle. Mais continuons et ajoutons l’implémentation:
+Comme vous pouvez le voir, nous avons ajouté deux simples tests pour savoir si l’utilisateur est connecté ou non. Et comme je l’ai déjà dit, c’est juste pour la clarté visuelle. Mais continuons et ajoutons l’implémentation:
 
 [source,ruby]
 .app/controllers/concerns/authenticable.rb
@@ -784,7 +784,7 @@ module Authenticable
 end
 ----
 
-Comme vous pouvez le voir, maintenant `authenticate_with_token!` est plus facile à lire non seulement pour vous mais pour aussi pour les autres développeurs qui rejoignerons le projet. Cette approche a également un avantage secondaire: si vous voulez modifier ou améliorer la façon de valider, vous pouvez simplement le faire sur la méthode `user_signed_in?`.
+Comme vous pouvez le voir, maintenant `authenticate_with_token!` est plus facile à lire non seulement pour vous mais aussi pour les autres développeurs qui rejoigneront le projet. Cette approche a également un avantage secondaire: si vous voulez modifier ou améliorer la façon de valider, vous pouvez simplement le faire sur la méthode `user_signed_in?`.
 
 Maintenant, nos tests devraient être tous verts:
 

fr/06_user_products.adoc

@@ -1,6 +1,6 @@
 == Produits des utilisateurs
 
-Dans le chapitre précédent, nous avons implémenté le mécanisme d’authentification que nous allons utiliser tout au long de l’application. Pour l’instant nous avons une implémentation très simple du modèle `User` mais le moment de vérité est venu où nous allons personnaliser la sortie JSON et ajouter une deuxième ressource: les produits utilisateurs. Ce sont les éléments que l’utilisateur vendra dans l’application, et par conséquent sera directement associé. Si vous êtes familier avec Rails, vous savez peut-être déjà de quoi je parle. Mais pour ceux qui ne le savent pas, nous allons associer le modèle `User` au modèle `Product` en utilisant les méthodes `has_many` et `belongs_to` de _Active Record_.
+Dans le chapitre précédent, nous avons implémenté le mécanisme d’authentification que nous allons utiliser tout au long de l’application. Pour l’instant nous avons une implémentation très simple du modèle `User` mais le moment de vérité est venu. Nous allons personnaliser la sortie JSON et ajouter une deuxième ressource: les produits de l'utilisateurs. Ce sont les éléments que l’utilisateur vendra dans l’application et par conséquent sera directement lié. Si vous êtes familier avec Rails, vous savez peut-être déjà de quoi je parle. Mais pour ceux qui ne le savent pas, nous allons associer le modèle `User` au modèle `Product` en utilisant les méthodes `has_many` et `belongs_to` de _Active Record_.
 
 Dans ce chapitre, nous allons construire le modèle de `Product` à partir de zéro, l’associer à l’utilisateur et créer les entrées nécessaires pour que tout client puisse accéder aux informations.
 
@@ -262,7 +262,7 @@ products.each do |product|
 end
 ----
 
-Nous sauvegardons d’abord les produits dans une variable pour un accès ultérieur, puis nous détruisons l’utilisateur et bouclons la variable des produits en nous attendant à ce que chacun des produits lance une exception. Tout mettre ensemble devrait ressembler au code suivants:
+Nous sauvegardons d’abord les produits dans une variable pour un accès ultérieur, puis nous détruisons l’utilisateur et bouclons la variable des produits en nous attendant à ce que chacun des produits lance une exception. Tout mettre ensemble devrait ressembler au code suivant:
 
 [source,ruby]
 .spec/models/user_spec.rb
@@ -328,7 +328,7 @@ Nous devons d’abord créer le `products_controller`, et nous pouvons facilemen
 $ rails generate controller api/v1/products
 ----
 
-La commande ci-dessus va générer pas mal de fichiers qui nous permettre de commencer à travailler rapidement. Ce que je veux dire par là, c’est qu’il va générer le contrôleur et les fichiers de test déjà _scopés_ à la version 1 de l’API.
+La commande ci-dessus va générer pas mal de fichiers qui vont nous permettre de commencer à travailler rapidement. Ce que je veux dire par là, c’est qu’il va générer le contrôleur et les fichiers de test déjà _scopés_ à la version 1 de l’API.
 
 [source,ruby]
 .app/controllers/api/v1/products_controller.rb
@@ -417,7 +417,7 @@ Comme vous pouvez déjà le constater, les tests et l’implémentation sont tr
 
 ==== Liste des produits
 
-Il est maintenant temps de créer une entrée pour liste de produits, qui pourrait permettre d’afficher le catalogue de produits d’un marché par exemple. Pour ce point d’accès, nous n’exigeons pas que l’utilisateur soit connecté. Comme d’habitude, nous allons commencer à écrire quelques tests:
+Il est maintenant temps de créer une entrée pour une liste de produits, qui pourrait permettre d’afficher le catalogue de produits d’un marché par exemple. Pour ce point d’accès, nous n’exigeons pas que l’utilisateur soit connecté. Comme d’habitude, nous allons commencer à écrire quelques tests:
 
 [source,ruby]
 .spec/controllers/api/v1/products_controller_spec.rb
@@ -499,7 +499,7 @@ $ git commit -m "Finishes modeling the product model along with user association
 
 ==== Création des produits
 
-Créer des produits est un peu plus délicat parce que nous aurons besoin d’une configuration supplémentaire pour donner une meilleure structure à ce point d’entré. La stratégie que nous suivrons est d’imbriquer les produits, dans les actions des utilisateurs. Ceci nous permettra d’avoir un point d’entrée plus descriptif comme `/users/:user_id/products`.
+Créer des produits est un peu plus délicat parce que nous aurons besoin d’une configuration supplémentaire pour donner une meilleure structure à ce point d’entrée. La stratégie que nous suivrons est d’imbriquer les produits, dans les actions des utilisateurs. Ceci nous permettra d’avoir un point d’entrée plus descriptif comme `/users/:user_id/products`.
 
 Notre premier arrêt sera donc le fichier `products_controller_spec.rb`.
 
@@ -550,7 +550,7 @@ RSpec.describe Api::V1::ProductsController, type: :controller do
 end
 ----
 
-Wow! Nous avons ajouté beaucoup de code. Si vous vous souvenez, les tests sont en fait les mêmes que ceux de la création de l’utilisateur exépté quelques changements mineurs. Rappelez-vous que nous avons cette route imbriquée, nous devons donc nous assurer d’envoyer le paramètre `user_id` à chaque requête, comme vous pouvez le voir sur:
+Wow! Nous avons ajouté beaucoup de code. Si vous vous souvenez, les tests sont en fait les mêmes que ceux de la création de l’utilisateur excepté quelques changements mineurs. Rappelez-vous que nous avons cette route imbriquée, nous devons donc nous assurer d’envoyer le paramètre `user_id` à chaque requête, comme vous pouvez le voir sur:
 
 [source,ruby]
 ----
@@ -713,7 +713,7 @@ class Api::V1::ProductsController < ApplicationController
 end
 ----
 
-Comme vous pouvez le constater, l’implémentation est assez simple. Nous allons simplement récupéré le produit auprès de l’utilisateur connecté et nous le mettons simplement à jour. Nous avons également ajouté cette action au `before_action`, pour empêcher tout utilisateur non autorisé de mettre à jour un produit.
+Comme vous pouvez le constater, l’implémentation est assez simple. Nous allons simplement récupérer le produit auprès de l’utilisateur connecté et nous le mettons simplement à jour. Nous avons également ajouté cette action au `before_action`, pour empêcher tout utilisateur non autorisé de mettre à jour un produit.
 
 Si on lance les tests, ils devraient passer:
 
@@ -886,4 +886,4 @@ $ git commit -m "Updates test environment factory gems to work on development"
 
 === Conclusion
 
-Dans le chapitre suivant, nous allons nous concentrer sur la personnalisation de la sortie des modèles utilisateur et produit à l’aide de la gemme _active model serializers_. Elle nous permettra de filtrer facilement les attributs à afficher et à gérer les associations comme des objets embarqués par exemple.
+Dans le chapitre suivant, nous allons nous concentrer sur la personnalisation de la sortie des modèles utilisateur et produits à l’aide de la gemme _active model serializers_. Elle nous permettra de filtrer facilement les attributs à afficher et à gérer les associations comme des objets embarqués par exemple.