23 réflexions sur « NipDev 1 – REST et développement d’APIs »

1. Interessant cet épisode sur les API 😉

   Le seul problème que je vois avec http la sécurité: à partir du moment où vous passez les paramètres en GET comme vous l’indiquez dans l’émission (fnac.com/clients/1234) vous passez tout le message en clair 🙁

   Niveau sécurité ce n’est pas top: et le risque de faille xsrf/rejeu and co … (quid du jeton??)

   Si au prochain épisode, vous parlez de frameworks php, pensez outre Zend Framework et Symfony à parler de framework plus modeste mais qui se donne du mal pour être confortable/sécurisé comme le mkFramework (cf sa page de tutoriel vidéos http://mkdevs.com/screencasts.html ) 😉
   Framework français sous licence LGPLv3 hebergé par developpez.com

   Répondre

   1. Je ne sais pas si la problématique de la sécurité a été évoquée ou non car je n’ai pas encore tout écouté mais comme cela a été dit dans la présentation, REST utilise le protocole http donc rien empêche d’utiliser l’https (cryptage des échanges => url, query params, body non visible) et coupler cela avec de l’authentification (Basic, oAuth, oAuth2, …).

      Pour le rejeu (et de même CSRF), amazon S3 propose un mécanisme l’empêchant (oAuth 1.0a aussi et sans doute d’autres frameworks « maison »). Ils utilisent tous les deux pour cela les headers de la requête avec un mécanisme de jetons et timestamps par exemple.

      Il faut bien comprendre que REST n’est pas un framework mais un concept…

      Répondre

      1. En https seul les données POST sont chiffrées, l’url, elle est en clair 😉

         Répondre

         1. En https, l’ensemble de la « couche » http est cryptée => url, headers, cookies, query param, … et non pas uniquement le body (http://en.wikipedia.org/wiki/HTTP_Secure )

            Seul le host et le port sont en réalité « visibles » car nécessaire à la couche TCP pour créer la connexion sécurisée.

            Répondre

            1. C’est sur ? Il me semblait avoir lu le contraire
               Par exemple: http://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/

            2. A lire plus en détail sur le sujet:
               Autant j’avais tort sur l’encryptage des paramètres GET lors de l’appel à la page (cf SSL…)

               Autant ces paramètres ne sont pas cryptées (donc sensible) dans certains cas: notamment la variable referer 🙁 (sans compter l’historique de navigation dans le cas d’un cybercafé, favoris…)

            3. Le passage de paramètres (y compris des paramètres fonctionnel type nom, …) dans l’url est couramment employé que ce soit pour des appels à des API ou de l’affichage de pages HTML et n’a jamais été à ma connaissance source de problèmes de sécurité. Globalement pour sécuriser les appels à une API REST, on emploie exactement les mêmes pratiques que pour la sécurisation d’un site Web. C’est l’un des avantages de REST d’ailleurs.

            4. Sur une application traditionnel ou par exemple on pourrait supprimer un enregistrement, afin de se prémunir d’une faille XSRF on utilise des jetons (pour eviter par exemple de supprimer un enregistrement à son insu, cf pratiques utilisant les failles XSRF)
               Dans une application traditionnel, on utilise les paramètres « visibles » comme l’url uniquement pour naviguer (voir un membre avec son id, lister des elements…) mais dès que l’on a des données sensibles (login/pass) on passe par du post ou des cookies de sessions (pour stoquer l’id de session)
               note: les cookies de session en httponly + si possible secure 😉

            5. Et à quoi sert SNI ?

            6. SNI ? pouvez-vous développer ?

            7. Oui biensur…
               Déjà, voici une petite description de SNI : http://en.m.wikipedia.org/wiki/Server_Name_Indication

               Quand tu as un serveur avec plein de Virtual Hosts en SSL, tu as souvent des problèmes avec les utilisateurs sous XP qui accèdent aux sites et qui ont des pbs avec les certificats (je bosse pour beaucoup de grosses entreprises françaises ou les employés sont toujours sous XP SP2).

               Le problème, c’est que quand leur requête HTTPS arrive dans ton serveur Apache, le serveur est à ce moment encore incapable de savoir à quel Virtual Host la requête est destinée parce ce que c’est le module Apache OpenSSL qui va décrypter le body, les headers, … Du coup, Apache par défaut va utiliser le premier Virtual Host et le certificat de ce VH n’a rien a voir avec celui du site donné. Donc l’utilisateur aura une erreur de certificat et comme on est dans des boites sérieuses 🙂 , l’accès au site est interdit.

               Arrive alors SNI, qui doit être supporté au niveau du browser et/ou de l’OS. SNI est une donnée claire qui transite avec tout le paquet crypté HTTPS qui permet simplement de signaler le domaine demandé au serveur.

               Si SNI a été mis en place, c’est justement parce que tout le paquet HTTP est crypté (URL, headers, body, …)

            8. Merci, je comprends mieux ce qu’est le SNI, mais pourquoi l’indiquez-vous par rapport à mon post ? que voulez-vous expliquer ?

            9. Je voulais juste expliquer que SNI a vu le jour parce que HTTPS crypte via SSL même l’url et les headers donc en conséquent les paramètres GET et les headers contenant le referrer.

      2. Effectivement, comme le dit Julien REST n’est pas un framework et donc n’apporte pas plus ou moins de sécurité qu’HTTP/HTTPS.

         Ceci étant dit, je pense que certains paramètres peuvent être passés en GET (donc dans l’URL) sans que cela pose un problème de sécurité. En l’occurence, est-ce que c’est l’ID du client (1234) qui est critique ? Car la ressource accessible à cette URL (le détail du client), elle, est nécessairement sécurisée : contrôle de l’identité de l’utilisateur (HTTP Basic, oAuth, authentification SSL mutuelle, ou autres solutions, …), contrôle de droits d’accès côté serveur, …

         Par contre les avantages d’avoir ce type d’URL « friendly » dans une application sont nombreux : mise en cache par le browser ou par les proxy, liens directs aux ressources (possibilité d’envoyer un lien direct vers un détail client par email par exemple), favoris de l’utilisateur, log des accès, …

         Répondre

2. Salut,

   Intéressant cet épisode!

   Je serai intéressé de savoir quels sont, parmi les CMS les plus courants (Drupal, WordPress, Joomla, Prestashop, Magento, osCommerce…), ceux qui utilisent un panier stocké sur le serveur et ceux qui préferent stocker le panier sur le client via des cookies (et qui donc peuvent plus facilement encaisser une montée en charge, comme vous l’avez dit).

   Répondre

   1. Salut François,

      Je ne connais pas assez les détails d’implémentation de ces CMS pour te répondre précisément. Je vois deux catégories de CMS parmi ceux que tu cites:

      – Les CMS génériques comme wordpress, joomla ou drupal ne possèdent pas à ma connaissance de gestion de panier par défaut et il faut ajouter des plugins pour avoir cette fonctionnalité. La gestion du panier dépend alors du plugin que l’on utilise.

      – Les outils dédiées à la création de site eCommerce comme prestashop, magento ou osCommerce possèdent une gestion de panier intégrée. Au feeling je dirais qu’elle se fait sur le serveur.

      Ceci dit, la gestion du panier sur le serveur n’est pas un frein absolu à la montée en charge. Elle mobilise plus de ressources qu’une gestion sur le client et c’est seulement si il y a plusieurs dizaines de connexions simultanées que l’on commence à percevoir une différence.

      Répondre

      1. Effetivement Drupal, WP et Joomla ne sont pas concernés.

         Oui il me semble aussi que Presta et osCommerce (Magento je ne l’ai jms utilisé) ont une gestion du panier sur le serveur. Je voulais confirmation.

         A priori je ne connais aucun CMS qui gère le panier sur le poste client. Il faut donc partir sur une solution maison si on veut cette fonctionnalité.

         Répondre

3. Félicitations pour ce podcast. Les deux premiers épisodes sont vraiment très bien ! Pour les frameworks d’API REST, je pense que vous pourriez aussi citer Restlet (www.restlet.org) qui est à mon avis très bien pensé pour ce besoin.

   Et puis c’était amusant de réentendre parler de CORBA & Co.. ça ne m’a pas rajeuni mais rappelé beaucoup de souvenir !!

   Longue vie à NipDev.

   Répondre

   1. Merci Olivier pour ces encouragements !

      Effectivement j’ai entendu du bien de Restlet mais je ne l’ai jamais utilisé moi même. Un point intéressant : apparemment on peut l’utiliser aussi directement dans Java SE, donc sans conteneur JEE…
      C’est vrai qu’il existe une multitude de framework pour faire du REST.

      A bientôt pour le prochain épisode !

      Répondre

4. Un petit commentaire de plus pour rendre jaloux Ben et Mike.

   Quelques compléments : un des intérêts d’une API HTTP/JSON par rapport à du XML est aussi le couplage lache au niveau du contrat de service (JSON comme javascript est très peu typé et donc très permissif, c’est donc plus facile de gérer les compatibilité de version mineure). Une fois que tu y as goutté et que tu dois faire un interfaçage SOAP avec un partenaire, tu pleures…

   Le pendant négatif est le manque de doc … (sujet évoqué ds le podcast). A ce propos, on a beaucoup utilisé enunciate (mais on est pas content du résultat et c’est intrusif .. annotation à rajouter.. ca a fait péter le build…). Swag rajoute aussi des annotations. Un des dev’ est donc partie sur un projet dédié qui va parser les annotations déjà existante pour en générer la documentation (https://github.com/PierreLeresteux/masterdoc-generator c’est au tout début).

   Sinon, le plus dur dans une API REST, c’est l’idempotence, y-a-t-il des retours de personnes qui ont réussi à le maintenir dans le temps sur leur API?

   Enfin, depuis quelque temps, j’utilise et fait utiliser un framework REST hypersimplifié en java : https://github.com/ybonnel/SimpleWeb4j c’est développé par un jugger régulier de bretagne et normandie. (JUG = Java User Group). Je l’ai fait utilisé par 2 stagiaires, comme ça il se concentre sur les vrai problème par sur la configuration de Spring ou du conteneur JEE. (C’est un peu une approche PHPiste – du simple pas de l’over engineering). Un exemple d’utilisation : https://github.com/youenchene/simpleSonarReporting/blob/master/src/main/java/fr/youenchene/simpleSonarReport/SimpleSonarReportController.java

   Bon courage pour la suite du podcast, j’ai trouvé le second numéro encore meilleur que le premier.

   Répondre

5. En terme de framework REST, il y a également restx (http://restx.io) qui se veut en rupture avec l’approche traditionnelle.

   En quelques points :

   – Framework opensource (sur github https://github.com/restx/restx) et initié par Xavier Hanin (le créateur d’Apache Ivy)

   – Minimaliste : une syntaxe « a la » JAX-RS/Restlet (annotations @Post, @Get etc…)

   – Evite le plus possible la reflection, en se reposant plutôt sur l’annotation processing

   – Très rapide (Xavier ne supporte pas qu’un serveur démarre en plus de 2s :-)) : vide, le serveur démarre en moins de 600ms (notamment grâce à l’annotation processing et au fait qu’il n’y ait pas de classpath scanning)

   – Moteur d’injection de dépendances compile-time (là encore, basé sur de l’annotation processing)

   – Documentation de l’API REST automatique, basée sur Swagger, et permettant de tester les points d’entrée REST

   – Tests d’intégration automatiques basés sur un fichier YAML de « specs », décrivant d’un coté les inputs (query params, body content de la request etc…) et de l’autre l’état de la base avant réception de la requête, puis en définissant l’output attendu en fonction de ces 2 contextes (syntaxe given/when/then)

   – Ces fichiers de specs peuvent également être utilisés pour fournir un serveur restx « mocké » se basant sur les fichiers YAML de spec (si vous envoyez une requête qui match une des requêtes YAML, l’output qui vous sera retourné sera celui du fichier YAML) => utile pour avoir un format pivot front + back pour paralléliser les devs sur ces 2 couches

   – Intégration avec MongoDB sous la forme d’un plugin, qui permet notamment de mettre le serveur en mode « recording » afin d’enregistrer l’état de la base sur chaque requête HTTP, et de générer les specs files adéquates (très utile pour générer des tests de non rég très rapidement)

   – Encore d’autres choses telles qu’un shell ou encore une console d’admin/monitoring

   Répondre

6. Bonjour !

   Merci 1000 fois pour cette entreprise. J’ai écouté avec intérêt les 2 premiers Podcasts en faisant mon footing, le niveau est bon, ça fait plaisir.

   J’aurais parlé en plus du concept de TestBed qui est totalement adapté aux REST API pour faciliter la vie aux développeurs. 100% d’accord avec Youen, retourner au SOAP fait juste pleurer. J’ai un souvenir douloureux d’une implémentation douteuse d’une REST API d’un grand service de train en France… 🙂 Le TestBed permet aux développeurs de générer et tester en live tous les appels. Il n’y a plus qu’un copier coller à faire dans son code et le tour est joué. Du coup, les développeurs utilisent plus facilement l’API.

   À la fin du 2nd podcast, vous demandiez quel sujet traiter. Voici quelques idées :
   – la scalabilité : comment concevoir une application webouvant supporter de 1 à quelques dizaines de millions de requêtes par jour sans investir dans une infra de dingue
   – algorithme utilisé par Google par exemple pour ses recherches
   – études d’attaques comme celle sur les DNS il y’a quelques semaines
   – DNSSec
   – …

   Je suis dispo si vous voulez des intervenants !

   Répondre

7. Salut, j’ai découvert tout récement NipTech, NipDev, Nip*, c’est avec plaisir que je vous écoute.
   Juste pour vous signaler que le lien vers « Un lien vers une excellente étude de Fabernovel sur le sujet. » est cassé, il faut désormais utiliser cette url : http://www.fabernovel.com/fr/work/6-reasons-why-apis-are-reshaping-your-business/
   Bonne continuation 🙂

   Répondre