REST Factory, simplifier les API REST

Discussions par date d’activité

2 discussions

• 7

  

  Holmes Pinto Avila

  Mars 2022

  J’implémente une API manuellement, en utilisant REACT comme front-end et SPIP comme back-end. Si quelqu’un est intéressé, je peux collaborer à la mise en œuvre.
  J’ai réussi à implémenter les deux et ça a été excellent !

  « Estoy implementado una Api manualmente, utilizando REACT como frond-end, y SPIP como Back-end. Si alguien esta interezado le puedo colaborar con la implementacón.
  Logre implementarla ambos y me ha ido excelente !! »

  • 

    paidge

    Janvier 2023

    J’avais la même idée pour VueJS. Mais pour l’instant j’ai un problème. Mon API REST fonctionne en local (sur deux postes avec Apache). Mais pas sur le serveur de production (un RPI4 sous proxy NGINX mais je n’ai pas la main sur la conf NGINX). SPIP me renvoie une page 404 alors que les dépôts sont les mêmes (mêmes version de SPIP, mêmes plugins, même BDD). Quelqu’un aurait une idée ?

    https://infojune.fr/http.api/ezrest/

  • 

    Eric Lupinacci

    Janvier 2023

    Hello,

    As-tu vérifié ton htaccess ?

  • 

    paidge

    Janvier 2023

    Merci pour ta réponse Eric. J’ai effectivement pensé au .htaccess. Mais j’ai le même fichier sous Windows/Apache que sous Linux/Nginx. Je me suis dit qu’il était peut-être ignoré sous Windows/Apache alors je suis allé voir dedans. A priori, c’est celui d’origine. J’ai essayé de commenter la ligne qui concerne les APIs pour voir mais sans résultat :
    https://pastebin.com/0q87WTtB

  • 

    Eric Lupinacci

    Janvier 2023

    Ok, non mais la ligne sur l’api est la bonne. Parfois on oublie d’activer le .htaccess à partir du fichier htaccess.txt mais a priori c’est pas le souci.

    J’avoue qu’à distance je ne vois pas ce qui peut poser problème surtout si tu arrives à faire fonctionner l’api en local.

  • 

    paidge

    Janvier 2023

    En fait, c’est tout simplement que NGINX ne supporte pas les .htaccess ^^
    Ce n’était donc pas l’environnement Windows/Apache qui ignorait le .htaccess mais l’environnement Linux/NGINX.
    Donc la règle à mettre à la racine du vhost dans NGINX :
    rewrite ^/([w] ).api([/.](.*))?$ /spip.php?action=api_$1&arg=$3 last;

  • 

    Loiseau2nuit

    Juin 2023

    4 mois après je rebondis sur ce message.

    Je ne sais pas si la syntaxe change en fonction de la version du server mais cette dernière règle ne fonctionne pas chez moi, en Nginx 1.18

    J’ai un nginx : [emerg] invalid number of arguments in « rewrite » directive qui empêche le serveur de redémarrer ... 🤔

  • 

    Loiseau2nuit

    Juin 2023

    OK, c’est résolu. La bonne syntaxe est en réalité la suivante (il faut mettre la ligne dans un bloc location { ... } sinon ça ne fonctionne pas.)

        # redirection des APIs
        location ~ /([\w]+).api([/.](.*))$ {
            rewrite ^/([\w]+).api([/.](.*))?$ /spip.php?action=api_$1&arg=$3 last;
        }

    Du coup j’ai mis à jour le wiki

  Répondre à ce message

• 3

  

  paidge

  Mai 2023

  Si on crée dynamiquement la liste des collections à exposer dans le pipeline liste_ezcollection (par ex en récupérant la liste des collections via lire_config()), est-ce que ça fonctionnerait bien en cas de modification des collections à exposer ou il faudrait supprimer un cache ou qqe chose du genre ?

  Même question avec des fonctions dynamiques du type :

  <?php
  $collection = "articles";
  $fonction_collectionner = $collection .  "_collectionner";
  $$fonction_collectionner = function($conditions, $filtres, $configuration) {
  	// Initialisation des données de la collection à retourner
  	$contenu = [];
  
  	// Récupération des données de la collection conformément aux filtres éventuellement fournis.
  
  	return $contenu;
  };
  
  $cond = array();
  $filt = array();
  $conf = array();
  $items = $fonction_collectionner ($cond, $filt, $conf);
  ?>

  • 

    paidge

    Mai 2023

    Je me demandais d’ailleurs s’il n’aurait pas été plus judicieux d’écrire les fonctions comme ça dans ezREST. Par exemple :

    function collectionner(string $collection, array $conditions, array $filtres, array $configuration) : array {
    	// Initialisation des données de la collection à retourner
    	$contenu = [];
    
    	return $contenu;
    }

    et de splitter tout le fichier prefixe.php dans différents fichiers. Par exemple : prefixe_contexte.php, prefixe_reponses.php, prefixe_verifier.php, prefixe_collectionner.php et prefixe_ressourcer.php

    Au pire, on doit pouvoir au moins splitter le fichier prefixe.php dans le plugin utilisateur grâce à des include non ? Parce qu’il devient vitre très long ce fichier :p

  • 

    Eric Lupinacci

    Mai 2023

    Pour définir les collections à exposer vu que cela passe par le pipeline liste_ezcollection on peut lire une configuration meta ou autre, il n’y a pas de souci.

    Pour les fonctions dynamiques faudrait essayer. Ce que je fais c’est que j’appelle dans le code ezREST une fonction d’api xxxx et que c’est elle qui aiguille vers la bonne fonction de service collection_xxxx ou prefixeplugin_xxxx suivant ce que l’on veut. Ces fonctions doivent être dans un include précis ezrest/prefixeplugin.php.

    Sinon, il est toujours possible de splitter l’include des services en plusieurs sous-includes et d’y faire appel dans l’include parent oui.

    Après, si tu as des besoins spécifiques il est toujours possible d’étudier des évolutions du plugin.

  • 

    Eric Lupinacci

    Mai 2023

    Autre chose, je te conseille de lire le guide conception qui est inclu dans le plugin « Guide - Le plugin REST Factory.pdf ». Il est plus complet que cet article et donne des exemples d’utilisation.

  Répondre à ce message