# La carte d’un restaurant exposée par une route REST plutôt que du HTML

> Quinze plats, un changement de carte chaque vendredi soir : fallait-il vraiment sortir l'artillerie d'une route REST sur mesure, ou un simple rendu HTML suffisait-il ?

- Auteur : WordPress Développement
- Publié le : 2020-04-02
- Mis à jour le : 2020-04-02
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/carte-restaurant-route-rest-plutot-que-html/

## L’essentiel

- Une route REST ajoute une couche technique à maintenir
- Le HTML classique reste imbattable pour un contenu peu volatile
- Le choix dépend du nombre de points d'affichage, pas du volume de plats

Quinze plats, un changement de carte chaque vendredi soir avant le service du week-end : c'est le cas concret qui a servi de base à ce comparatif, pour un restaurant de quartier qui voulait afficher son menu à la fois sur son site et sur un écran en salle. La question posée était simple : construire une route REST sur mesure pour cette carte, ou se contenter d'un gabarit WordPress classique en HTML ?

Les deux approches ont été testées sur le même contenu, avec le même volume de mise à jour hebdomadaire, pour mesurer où se situe réellement le seuil de rentabilité d'une architecture découplée face à un simple thème.

## Option A : un gabarit WordPress classique

La carte vit comme un ensemble de champs ACF rattachés à une page unique, affichés par un gabarit de thème standard, sans aucune route REST personnalisée. La mise à jour se fait dans l'éditeur, et le rendu apparaît immédiatement sur le site, sans étape de build ni de synchronisation.

Cette solution ne pose aucun problème tant qu'il n'existe qu'un seul point d'affichage. Le jour où l'écran en salle doit afficher la même carte, il faut soit scraper la page HTML publique, ce qui est fragile au moindre changement de gabarit, soit dupliquer la saisie, ce qui garantit tôt ou tard un désaccord entre les deux supports.

## Option B : une route REST personnalisée

La seconde approche expose la carte via une route dédiée, consommée à la fois par le site public et par l'application qui pilote l'écran en salle, sans jamais toucher au rendu HTML du thème.

```
register_rest_route( 'restaurant/v1', '/carte', array(
    'methods'             => 'GET',
    'callback'            => 'restaurant_get_carte',
    'permission_callback' => '__return_true',
) );

function restaurant_get_carte() {
    $plats = get_field( 'plats', 'option' );
    return rest_ensure_response( $plats );
}
```

> L'essentiel à retenir : Une route REST ajoute une couche technique à maintenir ; Le HTML classique reste imbattable pour un contenu peu volatile ; Le choix dépend du nombre de points d'affichage, pas du volume de plats

## Ce que révèle la mesure du temps de développement

Sur ce projet précis, la route REST a demandé environ une demi-journée de développement supplémentaire par rapport au gabarit classique, essentiellement pour structurer le format JSON de sortie et gérer les allergènes sous forme de tableau plutôt que de texte libre. Le gabarit HTML, lui, était opérationnel en une heure.

| Critère | Gabarit HTML | Route REST |
| --- | --- | --- |
| Temps de mise en place | Environ 1 heure | Environ 4 heures |
| Un seul point d'affichage | Suffisant | Surdimensionné |
| Écran en salle + site | Duplication de saisie | Source unique |
| Maintenance à long terme | Faible | Route à documenter |

## Un détail qui a failli faire pencher la balance

Un point n'apparaît dans aucun tableau comparatif classique : la gestion des allergènes. La réglementation impose un affichage précis par plat, et la structurer en tableau JSON plutôt qu'en texte libre a demandé une réflexion supplémentaire côté route REST, absente du gabarit HTML qui se contentait d'un champ texte affiché tel quel dans l'éditeur.

Cette contrainte réglementaire, propre à la restauration, a fini par jouer en faveur de la route REST : une fois les allergènes structurés en données plutôt qu'en texte, il devenait possible de les filtrer automatiquement côté écran en salle, ce qu'un simple champ de texte libre n'aurait jamais permis sans traitement supplémentaire.

## Le vrai critère de décision

Le volume de plats n'a presque aucune influence sur ce choix : une carte de quinze plats ou de cinquante plats se traite de la même façon techniquement. Ce qui fait basculer la décision, c'est le nombre de points d'affichage distincts qui doivent consommer la même donnée sans jamais diverger.

- Un seul affichage, mis à jour rarement : le gabarit HTML classique suffit largement
- Deux affichages ou plus, avec un risque de désynchronisation : la route REST devient rentable
- Un futur affichage tiers déjà planifié (application mobile, borne) : autant construire la route dès le départ

> Construire une route REST pour un contenu qui n'a qu'un seul lecteur, c'est payer aujourd'hui une flexibilité dont personne ne se servira demain.

## Notre verdict

Pour ce restaurant précis, avec un site vitrine et un écran en salle à alimenter, la route REST a été retenue malgré son coût de développement plus élevé, parce que l'alternative aurait imposé une double saisie hebdomadaire, source d'erreurs bien plus coûteuse à moyen terme qu'une demi-journée de développement initiale. Un établissement qui n'aurait eu qu'un site à mettre à jour aurait eu tort de faire le même choix. Ce comparatif ne traite pas la question du multilingue, qui aurait sensiblement changé l'équation en imposant une structure de données plus riche des deux côtés.