API REST en PHP

Version imprimable

14/01/2018, 16h01
kstor4U

API REST en PHP
Salut !

Je voudrais faire une application mobile capable de communiquer avec mon serveur.
Du coup, j'aimerais faire un API REST en PHP.

Après avoir lu quelques tutos, j'ai compris le principe mais il me reste deux questions sans réponse :
l'API n'est pas sensée avoir d'état... je comprends que l'API est supposée répondre toujours la même chose pour une même requête envoyée.
Comment je fais si je veux que le client n'ait accès qu'à certaines ressources selon ses identifiants ?
En gros, je vois deux solutions :
- garder une vaiable $_SESSION qui me permettra de savoir s'il est identifié.
- Garder coté client les ids et les renvoyer pour chaque requete au serveur. Cette solution est vachement lourde puisqu'elle m'oblige à vérifier ses accès à chaque requête.
Est-ce que je n'ai rien compris ou est-ce qu'il y a une meilleure façon de procéder?

Le second point est plus pratique : Si j'ai bien compris, on appelle une ressource par son sous dossier. Du coup, est-ce qu'il faut recréer l'arborescence complète sur le serveur et mettre un fichier PHP dans chaque dossier associé à une ressource ou existe-t-il un moyen de renvoyer toutes les requêtes à un index à la racine de l'API ?
La seconde solution me paraitrait plus efficace parce qu'elle permettrait d'éviter de répéter plein de choses telles que la connexion à la base et toutes les fonctions courantes.

Je vous remercie d'avance pour vos réponses.
14/01/2018, 23h16
mathieu

Citation:

Envoyé par kstor4U

Cette solution est vachement lourde puisqu'elle m'oblige à vérifier ses accès à chaque requête.

Dans le cas où vous générer un identifiant de session, vous devrez aussi vérifier si cette identifiant est encore valide à chaque requête donc cela revient à peu prêt au même

Citation:

Envoyé par kstor4U

Si j'ai bien compris, on appelle une ressource par son sous dossier.

le fait que l'URL ressemble à une suite de répertoire ne veut pas dire que les fichiers sur le serveur soient disposés de la même façon.
je connais des API REST qui redirige toutes les requêtes vers un fichier PHP unique qui analyse la requête pour choisir la réponse.
par exemple l'url exemple.com/gestion/clients/3 peut correspondre à l'espace de nom "Gestion", classe "Clients" et lecture du client avec l'identifiant 3.
15/01/2018, 09h01
grunk
Citation:
Envoyé par kstor4U

Comment je fais si je veux que le client n'ait accès qu'à certaines ressources selon ses identifiants ?
En gros, je vois deux solutions :

garder une vaiable $_SESSION qui me permettra de savoir s'il est identifié.
Garder coté client les ids et les renvoyer pour chaque requete au serveur. Cette solution est vachement lourde puisqu'elle m'oblige à vérifier ses accès à chaque requête.
La solution la plus courante est la suivante :
Une url permet de s'identifier. Par exemple /api/login.
On l'appel en fournissant login/mdp , en cas de succès de l'authentification l'API retourne un token qui identifie l'utilisateur. Voir par exemple JWT mais plein d'autre solution sont possible.
Le client fournit ensuite son token à chaque requête ce qui permet au serveur de vérifier à chaque requête si l'utilisateur est bien qui il dit être.

Une solution alternative plus simpliste est de mettre en place une authentification basic pour les url que tu veux protéger. Le client doit alors fournir login/mdp à chaque connexion. Je suis mois fan car tu expose régulièrement des données sensible. Ca impose évidemment du https.

Citation:

Envoyé par mathieu

je connais des API REST qui redirige toutes les requêtes vers un fichier PHP unique qui analyse la requête pour choisir la réponse.
par exemple l'url exemple.com/gestion/clients/3 peut correspondre à l'espace de nom "Gestion", classe "Clients" et lecture du client avec l'identifiant 3.

99% des API fonctionnent comme ça ;)
02/02/2018, 15h38
kstor4U

Salut,

Tout d'abord merci pour vos réponses.
Désolé pour la réponse tardive, j'avais mal réglé mes notifications...

Techniquement, comment je fais pour rediriger tous les sous dossiers vers un seul fichier en PHP ? Est-ce que ça se fait en réglant un .htaccess ? Est-ce qu'il y a une meilleure solution ?

Par rapport à l'identification, pour le token, si je comprends bien une variable SESSION ferait l'affaire ?
Pour JWT, c'est drole, j'avais réfléchi à faire la même chose^^.

Le fond de ma question était de savoir si à chaque fois qu'un client voudra faire un UPDATE (par exemple), il me faudra en plus de l'update faire les requêtes pour savoir s'il a le droit de modifier tel champ de tel élément ?
Est-ce que ça ne serait pas plus léger de stocker ses droits dans une variable SESSION ? Mais du coup, ça ne serait pas très REST ?

Merci d'avance pour votre réponse. (les notifications sont activées ^^).
02/02/2018, 16h52
grunk

Très souvent une url /api/login n'est pas une succession de sous dossiers mais un chemin virtuel. Toutes les url pointe sur un index.php via htaccess et c'est cet index qui décide quel fichier utiliser en fonction de l'url.

Citation:

Par rapport à l'identification, pour le token, si je comprends bien une variable SESSION ferait l'affaire ?

Pas de variable de session coté serveur puisque une api rest est stateless.
Le serveur recois le token du client et vérifie si il est valide. Si il l'est il a accès au contenu sinon ,on le bloque.

Citation:

Le fond de ma question était de savoir si à chaque fois qu'un client voudra faire un UPDATE (par exemple), il me faudra en plus de l'update faire les requêtes pour savoir s'il a le droit de modifier tel champ de tel élément ?

Soit les droits sont dans le token. Et tu décide donc en fonction du contenu du token. Soit tu préfère ne pas le rendre publique et il faut alors trouver qui est l'utilisateur grace au token et vérifier ses droits en fonction de son identité à chaque requête.
C'est le principale inconvenient de rest , comme c'est stateless il faut répéter certaines actions.
04/02/2018, 21h10
kstor4U

Citation:

Envoyé par grunk

Très souvent une url /api/login n'est pas une succession de sous dossiers mais un chemin virtuel. Toutes les url pointe sur un index.php via htaccess et c'est cet index qui décide quel fichier utiliser en fonction de l'url.
Pas de variable de session coté serveur puisque une api rest est stateless.
il faut alors trouver qui est l'utilisateur grace au token et vérifier ses droits en fonction de son identité à chaque requête.
C'est le principale inconvenient de rest , comme c'est stateless il faut répéter certaines actions.

Super, j'ai ma réponse.

Et ben ce ne sera pas REST !
Sinon, je vais passer mon temps à faire des jointures et bouffer des ressources pour rien.
Rien ne m'empêchera de faire du REST par la suite pour comparer.
Par contre, je vais utiliser le format REST (arborescence des ressources) pour que ce soit comprehensible.

Du coup, concrètement comment je renvoie toutes les requêtes à un index.php à la racine ? il y a mieux qu'un .htaccess ?

Merci encore
05/02/2018, 11h49
grunk
Comme je l'ai dit tu peux très bien inclure les droit d'utilisateurs dans le token. Ca implique juste d'invalider le token et donc forcer une réauthentification si les droits change.

Citation:

Du coup, concrètement comment je renvoie toutes les requêtes à un index.php à la racine ?

Par exemple :
Code:

1 2 3 4 5 RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !favicon.ico$ RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
Citation:

il y a mieux qu'un .htaccess ?

non
05/02/2018, 12h41
kstor4U

Salut,

Merci pour tes réponses.
C'est exactement ce que je voulais savoir.

Pour ce qui est du Token, c'est intéressant, j'ai lu cet article : http://blog.inovia-conseil.fr/?p=236
Pour l'instant je galère avec Ionic, je dois apprendre une chose à la fois, je retournerai sur le token si j'ai le temps.

Encore merci !

Pour le token , il existe plein de librairies dans la plus part des langages. Voir le site officiel à ce sujet.

Un exemple en php dans une de mes API pour générer un token en utilisant https://github.com/firebase/php-jwt:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 $token = array( "iss" => "dferBackend", //issuer "aud" => $cfg->url, // audience "iat" => time(), //Issued at "nbf" => time(), // Not valid before "jti" => base64_encode(random_bytes(32)), // json token id //"exp" => time()+60 "data" => [ 'uid' => $userDatas['id'], 'login' => $email, 'acl' => serialize($acl) ] ); $jwtKey = $cfg->jwtKey; echo JWT::encode($token, $jwtKey,'HS256');
Tu peux voir que dans la partie "data" j'ai une entrée "acl" qui correspond aux droits de l'utilisateur en cours. Il faut juste être conscient que cette information peut être lue par tout personne ayant accès au token. Elle ne peux en revanche pas être modifiée sans rendre le token invalide.
Comme pour un cookie on ne place donc pas de données sensible comme un mot de passe dans un token.