======Design et conception des Web API Rest====== ==== Ressources ==== * [[http://apigee.com/about/resources/ebooks/web-api-design|Doc PDF sur le design des API REST (en)]] * [[http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api|Bonnes pratiques pragmatiques pour les API REST (en)]] * [[http://yahooeng.tumblr.com/post/134800436351/elide-simplify-your-crud|Yahoo Elide]] * [[http://jsonapi.org/|JSON API]] * [[http://json-schema.org/|JSON Schema]] * [[http://v2.wp-api.org/|Wordpress REST API]] * [[https://github.com/18f/api-standards|API for business opportunities]] * [[http://fr.slideshare.net/apigee/restful-api-design-second-edition|Slideshare Resful API Design (2ème édition)]] * [[http://blog.mwaysolutions.com/2014/06/05/10-best-practices-for-better-restful-api/|10 bonnes pratiques pour les API REST (en)]] * [[https://zestedesavoir.com/tutoriels/422/la-theorie-rest-restful-et-hateoas/|Théorie REST et HATEOAS (fr)]] * [[https://api-platform.com/|API-Platform : solution PHP pour construire une API REST]] ==== Documentation d'API REST ==== * Voir le mémo sur ==== CORS et services REST ==== * [[https://remysharp.com/2011/04/21/getting-cors-working|CORS et REST]] * [[http://blog.inovia-conseil.fr/?p=202|Explication sur CORS]] * [[http://stackoverflow.com/questions/14467673/enable-cors-in-htaccess|Utilisation de htaccess et PHP pour CORS]] ==== HATEOAS ==== **HATEOAS :** fait de rajouter des liens vers les ressources et actions possibles dans les réponses des web services. La façon de renvoyer ces liens n'est pas standardisées. Les propositions actuelles : * [[http://stateless.co/hal_specification.html|HAL]], * [[http://json-ld.org/|JSON-LD]], [[http://www.markus-lanthaler.com/hydra/|Hydra]], * [[http://jsonapi.org/|JSON:API]], * [[http://json-schema.org/|JSON Schema]] ==== Mise en cache ==== * [[https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=fr|Gestion de l'entête Cache-Control]] * [[https://developers.google.com/speed/docs/insights/LeverageBrowserCaching?hl=fr|Entête HTTP utilisés dans le cadre de la gestion du cache côté navigateur]] * [[https://devcenter.heroku.com/articles/increasing-application-performance-with-http-cache-headers|Présentation des entêtes HTTP de gestion du cache]] ==== Création, modification et suppression multiples (bulk operation) ==== D'une façon générale, comme pour GET utiliser le filtrage à l'aide de la //query string// sur l'url indiquant l'ensemble des ressources. Exemples : * **[GET] /api/v1/users?id=1,2,3** : permet de récupérer seulement les utilisateurs dont l'id vaut 1, 2 ou 3. * **[POST] /api/v1/users** : passer dans le corps de la requête un tableau d'objets à ajouter. Le service web devra détecter la présence d'un objet simple ou d'un tableau d'objet pour savoir s'il doit ajouter un ou plusieurs éléments. Le statut de la réponse devrait être 303 et elle devrait contenir des liens vers l'ensemble des ressources créées. * **[PATCH] /api/v1/users?id=1,2,3** : permet de mettre à jour partiellement les utilisateurs d'id 1, 2 et 3. Le corps de la requête contient le champ à mettre à jour pour ces 3 utilisateurs. * **[PUT] /api/v1/users?id=1,2,3** : permet de mettre à jour les utilisateurs d'id 1, 2 et 3. . Le corps de la requête contient un objet avec les données à mettre à jour pour ces 3 utilisateurs. * **[DELETE] /api/v1/users?id=1,2,3** : permet de supprimer les utilisateurs dont l'id vaut 1, 2 ou 3. Ressources : * [[http://stackoverflow.com/a/17301109|Solution de "RESTful Webservices Cookbook" (O'Reilly)]] * [[http://programmers.stackexchange.com/questions/191596/is-it-ok-to-partially-change-a-collection-with-put-or-delete|Changement partiellement une collection avec PUT ou DELETE]] * [[http://stackoverflow.com/questions/4954134/rest-deleting-a-collection-of-objects|REST : supprimer une collection d'objets]] * [[http://stackoverflow.com/questions/21863326/delete-multiple-records-using-rest|Supprimer plusieurs enregistrements avec REST]] ==== Authification et REST ==== Dans chaque web service suivant (hormis pour le POST), le token est transmis dans un header (//Authorisation: Bearer //). Normalement, l'ensemble des accès aux web services doivent se faire en HTTPS pour éviter le vol de token (//Man in the middle//). * **[GET] /authentication?verify=true** : pour vérifier le token courant (L'utilisateur existe-t-il toujours ? Le token est-il toujours valide ? Le token n'a-t-il pas été blacklisté ?). * **[GET] /authentication?refresh=true** : pour rafraichir le token courant. Vérifie la validité du token et le met à jour la date de validité du token. * **[POST] /authentication** : pour s'identifier. Identifiant (courriel) et mot de passe doivent être transmis dans le corps de la requête. Le mot de passe peut être transmis sous forme de hash. * **[DELETE] /authentication** : : pour se désidentifier. Une réponse 204 doit être renvoyé si tout est ok. Ressources : * [[http://stackoverflow.com/questions/15051712/how-to-do-authentication-with-a-rest-api-right-browser-native-clients|Retour d'expérience]] ==== Les verbes ==== Pour certains types de ressources, il peut être utile d'utiliser des verbes : * calculate * convert * search * count