# Coopérative agricole : diffuser ses cours du jour par un endpoint public

> Les cours changent à six heures du matin, avant l'ouverture du marché. Comment une coopérative agricole expose ses tarifs du jour via une route REST, consommée par un afficheur et par son site public.

- Auteur : WordPress Développement
- Publié le : 2022-02-17
- Mis à jour le : 2022-02-17
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/cooperative-agricole-cours-du-jour-endpoint-public/

## L’essentiel

- Les cours du jour vivent comme un type de contenu daté, pas comme des pages
- Une route dédiée renvoie uniquement le cours en vigueur au moment de l'appel
- Le même endpoint alimente un afficheur physique et le site public

Les cours changent à six heures du matin, avant l'ouverture du marché, et doivent être visibles à la fois sur un afficheur électronique installé à l'entrée du site de collecte et sur le site public consulté par les producteurs adhérents. Cette contrainte a orienté toute l'architecture d'une coopérative agricole vers un unique endpoint REST, plutôt que deux systèmes distincts maintenus en parallèle.

Le contenu à exposer, en apparence trivial, cachait une difficulté récurrente : il fallait toujours renvoyer le cours actuellement en vigueur, jamais un historique complet, et jamais un cours futur déjà saisi en prévision d'un changement de tarif programmé.

## Modéliser un cours comme un contenu daté

Chaque cours a été enregistré comme une entrée d'un type de contenu `cours_jour`, avec une date d'entrée en vigueur en métadonnée, plutôt que de modifier une seule page à chaque changement de tarif :

```
register_post_type( 'cours_jour', array(
    'label'        => 'Cours du jour',
    'public'       => false,
    'show_in_rest' => true,
    'supports'     => array( 'title', 'custom-fields' ),
) );
```

Le choix de `public` à `false` retire ce type de contenu de la navigation classique du site, tout en conservant son exposition possible via une route REST personnalisée, seule interface prévue pour le consulter.

## Une route qui ne renvoie que le cours en vigueur

```
register_rest_route( 'cooperative/v1', '/cours-actuel', array(
    'methods'             => 'GET',
    'callback'            => 'cooperative_get_cours_actuel',
    'permission_callback' => '__return_true',
) );

function cooperative_get_cours_actuel() {
    $query = new WP_Query( array(
        'post_type'      => 'cours_jour',
        'posts_per_page' => 1,
        'meta_key'       => 'date_entree_vigueur',
        'meta_compare'   => '<=',
        'meta_value'     => current_time( 'Y-m-d H:i:s' ),
        'orderby'        => 'meta_value',
        'order'          => 'DESC',
    ) );
    return rest_ensure_response( $query->posts );
}
```

> L'essentiel à retenir : Les cours du jour vivent comme un type de contenu daté, pas comme des pages ; Une route dédiée renvoie uniquement le cours en vigueur au moment de l'appel ; Le même endpoint alimente un afficheur physique et le site public

## Deux consommateurs, un seul endpoint

L'afficheur électronique installé physiquement sur le site de collecte interroge cette route toutes les cinq minutes via une petite application embarquée, tandis que le site public destiné aux producteurs adhérents affiche la même donnée dans une simple section de sa page d'accueil, rafraîchie à chaque chargement.

- Un seul point de vérité pour le cours en vigueur, sans risque de désynchronisation entre affichage physique et site public
- Une saisie anticipée possible, sans jamais exposer un cours dont la date d'entrée en vigueur n'est pas encore atteinte
- Aucune authentification requise, la donnée étant volontairement publique une fois en vigueur

## Le piège du fuseau horaire pour une saisie anticipée

La comparaison de dates dans la requête utilise `current_time()` plutôt que `date()`, afin de respecter le fuseau horaire configuré dans WordPress plutôt que celui du serveur. Une confusion entre les deux aurait pu faire apparaître un cours prévu pour six heures du matin avec plusieurs heures d'avance ou de retard selon la configuration du serveur d'hébergement.

> Une donnée qui change chaque jour à heure fixe mérite une requête qui raisonne en heure locale du site, pas en heure du serveur qui l'héberge.

## Anticiper une saisie plusieurs jours à l'avance

Un responsable de la coopérative a demandé, en cours de projet, la possibilité de saisir un cours plusieurs jours avant son entrée en vigueur, par exemple avant un congé prévu. La requête initiale gérait déjà correctement ce cas sans modification supplémentaire, puisqu'elle ne retient que le cours le plus récent dont la date d'entrée en vigueur est déjà passée, ignorant naturellement toute saisie future en attente.

Ce comportement, non explicitement demandé au départ mais obtenu presque par construction grâce à la logique de tri par date, a évité un développement supplémentaire qui aurait été nécessaire avec une structure de données moins rigoureuse dès le départ.

## En résumé

Un type de contenu daté, combiné à une route REST qui filtre elle-même la donnée en vigueur plutôt que de laisser cette logique au client, a permis à cette coopérative de tenir à jour un affichage cohérent sur deux supports distincts sans jamais dupliquer la saisie. Ce cas ne traite pas la question de l'authentification, la donnée étant volontairement accessible sans restriction une fois publiée.