# _fields limite une requête REST aux données utiles au front headless

> Un paramètre global de l'API REST permet de ne recevoir que les champs réellement affichés côté front, sans toucher au contrôleur ni à son schéma.

- Auteur : WordPress Développement
- Publié le : 2022-01-14
- Mis à jour le : 2022-01-14
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/fields-limite-requete-rest-donnees-utiles-front/

## L’essentiel

- _fields fonctionne sur toute route qui expose un schéma
- La syntaxe pointée cible un champ imbriqué précis
- Le gain de poids dépend directement du nombre de champs ignorés

```
GET /wp-json/wp/v2/posts?_fields=id,title,slug,excerpt
```

Cette requête ne renvoie que quatre champs par article, là où une requête classique sur la même route en renverrait une vingtaine, incluant du contenu HTML complet, des métadonnées de modèle, des liens hypermédia et bien d'autres informations rarement affichées sur une simple page de liste. Le paramètre `_fields`, disponible globalement sur l'API REST de WordPress, permet cette réduction sans écrire la moindre ligne de code côté serveur.

## Étape 1 : repérer les champs réellement utilisés

Avant d'appliquer `_fields`, il faut identifier précisément ce que le front affiche sur la vue concernée. Sur une page de liste d'articles, typiquement : le titre, l'extrait, l'image mise en avant, la date et le lien vers l'article complet. Tout le reste — contenu complet, méta-données de commentaires, informations de licence — n'a aucune utilité tant que l'utilisateur n'a pas cliqué sur l'article pour accéder à sa page de détail.

## Étape 2 : construire la liste de champs

```
fetch('https://exemple.test/wp-json/wp/v2/posts?_fields=id,slug,title,excerpt,date,_links.wp:featuredmedia')
  .then(res => res.json())
  .then(articles => console.log(articles));
```

La syntaxe pointée, comme dans `_links.wp:featuredmedia`, permet de cibler un champ imbriqué précis à l'intérieur d'une structure plus large, plutôt que de devoir choisir entre tout inclure ou tout exclure une section entière de la réponse. Sans cette précision, demander `_links` seul renverrait l'intégralité de la section des liens hypermédia, y compris ceux jamais utilisés par le front.

> L'essentiel à retenir : _fields fonctionne sur toute route qui expose un schéma ; La syntaxe pointée cible un champ imbriqué précis ; Le gain de poids dépend directement du nombre de champs ignorés

## Étape 3 : combiner avec _embed si nécessaire

Sur une liste qui affiche aussi l'image mise en avant, combiner `_fields` avec `_embed` reste tout à fait possible, à condition de cibler également les champs de la section embarquée :

```
GET /wp-json/wp/v2/posts?_embed=wp:featuredmedia&_fields=id,title,excerpt,_embedded
```

Sans préciser un sous-champ de `_embedded`, cette section reste incluse dans son intégralité, ce qui limite un peu le gain par rapport à un ciblage encore plus fin sur, par exemple, uniquement `_embedded.wp:featuredmedia.0.source_url`.

## Étape 4 : mesurer le gain

Sur un article typique de ce projet, une réponse complète pesait environ 4,8 kilo-octets par article dans une collection de dix éléments, soit près de 48 kilo-octets pour une seule page de liste. En limitant les champs aux cinq réellement affichés, la même collection descendait à environ 1,9 kilo-octet par article, soit une réduction de plus de la moitié du poids total transféré — un gain particulièrement sensible sur une connexion mobile ou un affichage en défilement infini qui multiplie les appels.

## Étape 5 : vérifier les effets de bord

- Un champ absent de `_fields` ne déclenche jamais d'erreur ; il est simplement omis de la réponse, sans avertissement
- Certains plugins qui ajoutent des champs personnalisés via `register_rest_field()` respectent ce filtrage global ; d'autres l'ignorent selon la façon dont leur callback de récupération est implémenté
- Le filtrage s'applique après l'exécution complète du contrôleur : il réduit la réponse transmise, mais ne réduit pas le travail effectué côté serveur pour la construire

## Une limite à connaître

Ce dernier point mérite d'être souligné : `_fields` agit en toute fin de traitement, sur la réponse déjà entièrement construite. Une route qui effectue des calculs coûteux pour générer un champ finalement filtré continuera d'effectuer ce calcul à chaque requête, même s'il n'apparaît jamais dans la réponse finale. Pour réduire réellement la charge côté serveur, il faut agir en amont, sur le contrôleur lui-même, et non se reposer uniquement sur ce paramètre côté client.

## En résumé

Le paramètre `_fields` reste l'un des moyens les plus simples de réduire le poids d'une réponse REST côté front headless, sans toucher à un seul contrôleur ni écrire de code serveur supplémentaire. Il ne remplace pas une optimisation côté serveur pour les routes réellement coûteuses à calculer, mais il constitue un premier réflexe rentable dès qu'un front n'a besoin que d'une fraction des données exposées par une route.