8797 sujets

Développement web côté serveur, CMS

[Résolu] Ajax + REST

Hello.

Je bosse actuellement sur un site sur lequel je compte employer un maximum l'API History (push State), pour faire du pjax pour les navigateurs le supportant. J'aimerais bien essayer de faire ça avec une archi REST propre, soit une URI = une ressource.

De ce que j'en ai compris, en REST, on doit utiliser l'entête Accept pour spécifier le mime/type de la ressource (json, xml etc).

Dans mon cas, je n'ai que deux représentations : mon HTML "complet" avec header + contenu + footer (si pas de pushState) et mon html "simplifié" avec juste le contenu (dans le cas d'une requête ajax).

Sachant que jQuery envoie une entête particulière lors d'une requête Ajax (HTTP_X_REQUESTED_WITH), est-ce correct d'un point de vue REST de différencier les deux représentations côté serveur en se basant là-dessus, ou est-ce que cette façon de procéder "viole le contrat" et je dois demander un mime/type différent?

Tout cela étant encore pas mal embrouillé dans ma petite tête, merci d'avance à qui pourra m'éclairer.
JE ne sais pas si cela répond vraiment à ta question, mais dans Symfony (si tenté qu'un framework mondialement réputé puisse servir d'exemple), la méthode isXttpRequest() permettant de détecter si la page est appelée via une requête Ajax ou non, tuilise cette fameuse entête HTTP_X_REQUESTED_WITH.
/**
* Returns true if the request is a XMLHttpRequest.
*
* It works if your JavaScript library set an X-Requested-With HTTP header.
* Works with Prototype, Mootools, jQuery, and perhaps others.
*
* @return bool true if the request is an XMLHttpRequest, false otherwise
*/
public function isXmlHttpRequest()
{
  return ($this->getHttpHeader('X_REQUESTED_WITH') == 'XMLHttpRequest');
}

On peut donc en déduire que c'est une méthode fiable pour gérer les appels Ajax.

Mais ta question portant sur REST je ne suis pas sur que ça soit la bonne méthode étant donné qu'une requête doit retourner la même donnée, éventuellement dans un format (json, xml...) déférent.
Je ne suis pas spécialiste du REST mais j'aurai tendance à penser que la logique voudrait que l'option pour ajouter ou non ton layout devrait être définie dans la requête.
En fait le souci ne vient pas de l'implémentation, l'entête HTTP_X_REQUESTED_WITH est belle est bien envoyée lors des requêtes Ajax par la plupart des frameworks JS actuels (via XMLHttpRequest.setRequestHeader pour ceux que ça intéresse), et facilement testable (cf ton exemple, ou plus simplement tester $_SERVER).

Le souci pour moi est plus de savoir si le fait d'avoir deux représentations différentes via le même mime-type d'une ressource est correct d'un point de vue REST ou pas.

Après, je pose la question plus pour ma culture générale qu'autre chose, ce n'est de toute façon pas du code destiné a devenir une API ouverte.
Modifié par Florian_R (31 May 2012 - 10:18)
Je ne suis pas sûr que ça soit invalide, mais ce n'est sans doute pas la meilleure pratique.

Une ressource peut voir différentes représentations.
Le type de représentation peut être demandé grave à l'uri (donc plusieurs uris pour une même ressource, ce qui peut être dérangeant) ou aux headers HTTP (Accept, Accept-Charset, Accept-Encoding, Accept-Language).
Dans le cas des headers, on met en place une négociation client serveur, dirigée par le serveur ou le client.

Des développeurs utilisent des headers customs, mais ce n'est pas l'approche que je recommanderais.
Modifié par paolo (31 May 2012 - 14:26)
Bonjour,

Il n'y a pas vraiment de question de validité ici à mon avis ; pour autant que je sache, REST n'est pas une spécification.

Je suis d'accord pour dire qu'il ne faut pas se baser sur l'en-tête X_REQUESTED_WITH pour déterminer le type de données à renvoyer.

Je pense qu'il vaut mieux passer par l'en-tête Accept voire par un paramètre de requête.
Modifié par Julien Royer (31 May 2012 - 14:35)
Julien Royer a écrit :
Il n'y a pas vraiment de question de validité ici à mon avis ; pour autant que je sache, REST n'est pas une spécification.
Sans être une spécification, toutes les API que j'ai pu voir dégage des conventions dans l'utilisation, d’où mon intérêt pour faire ça de "la bonne façon".

Paolo a écrit :
Des développeurs utilisent des headers customs, mais ce n'est pas l'approche que je recommanderais.
Julien Royer a écrit :
Je pense qu'il vaut mieux passer par l'en-tête Accept voire par un paramètre de requête.
Donc en résumé, une url du type truc.com/ressources/id/?light=true pour les requêtes ajax, avec un Accept text/html? Dans la mesure ou je ne fais que du GET, ça me semble cohérent.
Florian_R a écrit :
Sans être une spécification, toutes les API que j'ai pu voir dégage des conventions dans l'utilisation, d’où mon intérêt pour faire ça de "la bonne façon".

Donc en résumé, une url du type truc.com/ressources/id/?light=true pour les requêtes ajax, avec un Accept text/html? Dans la mesure ou je ne fais que du GET, ça me semble cohérent.

Ou même truc.com/resources/id?light Smiley smile
Modifié par Julien Royer (31 May 2012 - 15:55)
Sujet clos
Aller à