Architecture REST & API Restful

Architecture REST & API Restful

REST est devenu, depuis ses quelques dernières année, un style d’architecture incontournable pour la création de services web.

Après un gros rappel sur ce qu’est REST, nous analyserons l’écosystème de celui-ci, et je vous fournirai des pistes pour créer des API RESTful (également appelées Hypermédia).

Pour étayer mes propos, j’accompagnerai ce talk avec une démonstration d’APIPlatform, un nouveau framework RAD pour la mise en place d’API REST solide et rapide avec Symfony.

8d26b5d9c10abb80a42e6ba9dfa47dfa?s=128

Perussel Nicolas

September 28, 2017
Tweet

Transcript

  1. Architecture REST & API RESTful Nicolas Perussel 28 Septembre 2017

    AFUP BORDEAUX
  2. ORIGINE DE REST Salut, je m’appelle Roy Fielding et j’ai

    écrit une thèse en 2000 Architectural Styles and the Design of Network- based Software Architectures  REST veut dire « Representational State Transfer »  La thèse de Roy est dispo ici (Fr) : http://opikanoba.org/tr/fielding/rest/*  REST est une architecture et non un protocole (à l’inverse de SOAP)  REST repose sur HTTP (RFC 7230)
  3. ORIGINE DE REST "Representational State Transfer évoque l'image du fonctionnement

    d'une application Web bien construite : un réseau de pages Web (une machine à états finis virtuelle) où l'utilisateur progresse dans l'application en cliquant sur des liens (transition entre états) ce qui provoque l'affichage de la page suivante (représentant le nouvel état de l'application) à l'utilisateur qui peut alors l'exploiter" C’est Roy qui l’a dit !
  4. REST - CONSTRAINTS REST is CLIENT-SERVER REST use CACHE REST

    is STATELESS REST INTERFACE / Uniform Contract REST is based on LAYERED SYSTEM REST CODE ON DEMAND (allow logic within client)
  5. RMM (Richardson Maturity Model) Salut, je m’appelle Leonard Richardson et

    je suis à l’origine du : Richardson Maturity Model Martin Fowler m’a rendu célébre !
  6. RMM (ZOOM) Single URI and Single HTTP VERB Multiple URI

    and Single HTTP VERB Multiple URI addressable Resources and Multiple HTTP VERB HATEOAS Hypermedia As The Engine Of Application State
  7. RMM LEVEL 0 Request send on SAME URL Fuck status

    code ALWAYS 200 Request send with POST VERB Send XML
  8. RMM LEVEL 1 Add RESOURCE POST /agenda POST /actualites Hierarchical

    VIEWS POST /actualites/56
  9. RMM LEVEL 2 Use HTTP VERB GET, POST, PUT, DELETE

    GET /actualites/56 POST /actualites PUT /actualites/56 DELETE /actualites/56 Introduce HTTP CODE 1xx : "Je suis en train de bosser, attends encore un peu." 2xx : "Voilà le résultat, ça s'est bien passé." 3xx : "Le contenu est déplacé, va voir ailleurs (cf. en-tête location)." 4xx : "Tu me demandes n'importe quoi, tu as merdé." 5xx : "J'ai merdé... " https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
  10. BUZZWORDS (quelques-uns…)

  11. Qu’est ce qui me veut avec son Level 3 ?

  12. HYPERMEDIA API découvrables VOCABULAIRES réutilisables FORMATS réutilisables Technique ou système

    permettant, dans un système Documentaire multimédia, de passer d'un document à un autre selon des chemins préétablis ou élaborés lors de la consultation.
  13. HYPERMEDIA Types de médias (formats) • Collection + JSON •

    SIREN • HAL • JSON API • JSON-LD & HYDRA  W3C (2014) Sémantiques (vocabulaires) • Link relations IANA • Schema.org • Microformats
  14. JSON-LD Format Hypermedia standardisé : recommandation W3C (2014) Easy to

    use : document JSON standard avec des clés spéciales (@) ==> mapping vers un context Promu par Google, BBC, Microsoft, US & UK gouvernments Adapaté pour le Web semantic : RDF, SPARQL, Triple Store …
  15. JSON-LD

  16. Extension de JSON-LD (Draft du W3C) Documentation d’une API JSON-LD

    Permet à une API d’être auto-découvrable par le client :  Ressources disponibles  Propriétés des ressources  Types et opération  Règles de validations Propose un format standardisé pour :  Collections  Paginations  Filtres  Erreurs … HYDRA
  17. API PLATFORM RAD API avec API PLATFORM & WEBBY

  18. API PLATFORM RAD API avec API PLATFORM & WEBBY Gérer

    vos ressources POUR CHAQUE RESSOURCES:  Choix des verbes * : GET / POST / PUT / DELETE / OPTIONS / HEAD  Choix des propriétés *  Choix des ressources embarquées *  Création de « Controllers » & « Routes » spécialisés FACILITER GRACE AUX ANNOTATIONS ! *
  19. API PLATFORM RAD API avec API PLATFORM & WEBBY Filtrer

    vos API facilement • SEARCH : exact, partial, start, end, and word_start • DATE : ?property[<after|before|strictly_after|strictly_before>]=value • BOOLEAN : ?property=[true|false|1|0] • NUMERIC : ?property=int|bigint|decimal... • RANGE : ?property[lt]|[gt]|[lte]|[gte]|[between]=value • ORDER : ?order[property]=<asc|desc> • GROUP: ?groups[]=<group> • PROPERTY : ?properties[]=<property> FACILE JE VOUS DIS !
  20. API PLATFORM RAD API avec API PLATFORM & WEBBY Valider

    vos ressources • Utilise le ValidatorComponent • Validation groups
  21. API PLATFORM Sérialiser vos ressources • Etant le SerializerComponent •

    Transforme les objets PHP vers Hydra • Data Providers sont ont cœur du système • Serializer disponibles : • JSON-LD (api_platform.jsonld.normalizer.item) • HAL (api_platform.hal.normalizer.item) • JSON, XML, CSV, YAML (using the Symfony serializer) (api_platform.serializer.normalizer.item) • Facilement (presque) extensible
  22. API PLATFORM PHP ROCKS ! RAD API avec API PLATFORM

    & WEBBY
  23. Merci de votre écoute http://putaindecode.io/fr/articles/api/hateoas/ https://martinfowler.com/ https://json-ld.org/ http://www.hydra-cg.com/ https://api-platform.com/ Sources

    :