REST parti d'un thèse à lire : Roy Fielding 2000

  • Ressource adressable -> url
  • Interface uniforme -> GET , POST, PUT, DELETE
  • Représentation multiple -> je transmet une représentation de ce qui est identifié
  • PUT url <- sous entends que je connais l'url que la ressource aura, avant même qu'elle n'existe
  • POST url <- sous entends que je ne connais pas encore l'url que la ressource aura, elle me sera indiquée dans le retour.

GET et PUT devraient TOUJOURS retourner la même chose. POST jamais.

HEAD et OPTIONS HEAD -> comme GET mais on ne reçoit en retour que les header, pas le corp de réponse

OPTIONS url

retourne les commandes utilesable sur l'url

En retour, on a 404, 201, 303, 500 , .... 303 <- url de ce que post a créé

Dans la requete, on peut envoyer un "accept" avec les mime/type accepté en retour

Stateless

-> chaque requête contient TOUTES les infos (pas de sessions)

lire pour approfondir : connexité

Faites du bon REST sur GET -> énormément d'occasion d'avoir du cache. -> idéal dans les favoris. -> clients plus faciles.

Les faux REST : POX ou REST-RPC (Flickr, Upcomming.org,...) Twitter parce qu'il utilise que GET POST

M*rde il ne reste que 5 minutes

REST et php : pas de $_PUT

Zend_Server_Rest <- en fait c'est POX Zend_Rest_Route <- C'est nouveau.