• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
REST - deSymfony2012
 

REST - deSymfony2012

on

  • 7,449 views

Repasaremos conceptos y principios para que una arquitectura sea RESTfull, se explicará cómo se ha plateado el framework Leophard para seguir estos y otros principios.

Repasaremos conceptos y principios para que una arquitectura sea RESTfull, se explicará cómo se ha plateado el framework Leophard para seguir estos y otros principios.

Statistics

Views

Total Views
7,449
Views on SlideShare
2,711
Embed Views
4,738

Actions

Likes
4
Downloads
90
Comments
0

33 Embeds 4,738

http://www.symfony.es 1680
http://magdkudama.com 831
http://blog.liip.ch 703
http://desymfony.com 499
http://symfony.es 437
https://blog.liip.ch 224
http://feeds.feedburner.com 102
http://www.webcomparte.cl 66
http://www.desymfony.com 44
http://desymfony.es 33
http://asier.sp.in 23
http://blog.local 19
http://librosweb.es 18
http://speakerin.com 14
http://192.168.11.11 6
https://twimg0-a.akamaihd.net 6
http://www.aggregator.ch 4
https://si0.twimg.com 4
http://192.168.11.10 3
http://5.135.163.193 3
http://www.newsblur.com 3
http://desymfony.acilia.es 3
http://www.desymfony.es 2
http://www.magdkudama.com 2
http://translate.googleusercontent.com 1
http://www.speakerin.com 1
https://www.linkedin.com 1
http://www.linkedin.com 1
http://ranksit.com 1
http://symfony.local 1
http://www.sfexception.com 1
http://desymfony.local 1
http://tech.local 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    REST - deSymfony2012 REST - deSymfony2012 Presentation Transcript

    • HolaAsier MarquésSimettric, Fundador.4VisionsManager.com, Socio y director técnico.
    • Desacoplar el cliente del backend• Mayor escalabilidad• Separación de problemas• División de especialidades• API uniforme para todos los clientes
    • REST
    • RESTREpresentational State TransferUn estilo de arquitectura paradesarrollar aplicaciones web distribuidasque se basa en el uso del protocoloHTTP e Hypermedia.Definido en el 2000 por Roy Fielding
    • Una buena API RESTNo tiene estado en el backend.Está desacoplado del cliente.Dispone de una interfaz uniforme(basada en URIs)
    • Richardson Maturity Model# Nivel 1 (Pobre): Se usan URIs para identificar recursos# Nivel 2 (Medio): Se usa el protocolo HTTP adecuadamente# Nivel 3 (Óptimo): Se implementa hypermedia.http://www.crummy.com/writing/speaking/2008-QCon/act3.html
    • Recursos, URIs, hypermedia?
    • REST: Nivel 1URIs
    • URI, uniform resource identifier Identifica un recurso Pueden identificar un recurso por nombre (URN) o por localización (URL)
    • Recurso?
    • Recursos/users Listado de usuarios/users/{id} Un usuario
    • Reglas para identificar recursos• Se debe *identificar* un recurso!• Las URIs se construyen con nombres nunca con verbos• Deberían tener una estructura jerárquica
    • URIs incorrectasNunca se usan verbos/getUser/{id}/users/{id}/edit/loginDeben ser jerárquicas/invoices/user/{id}Identifican un recurso/invoices/page/2
    • URIs válidasNunca se usan verbos/users/{id}/users/{id}/access-tokenDeben ser jerárquicas/user/{id}/invoicesIdentifican un recurso/invoices/?page=2
    • FormatosNo se debería indicar el formato en laURI, el formato no identifica al recurso/invoices.html/invoices.css/invoices.xml
    • Para eso está HTTPRequest:GET accept: text/html /invoicesResponse:200 content-type: text/htmlResponse:406 Not Acceptable
    • REST: Nivel 2HTTPcomo framework
    • HTTP como Framework• Protocolo de transporte• Métodos• Códigos de estado• Content-Type• Gestión de versiones• Cache
    • HTTP: MétodosGET Recupera el recursoPOST Crea un nuevo recursoPUT Edita el recursoPOST/PATCH Edita el recurso parcialmenteDELETE Elimina el recurso
    • MétodosRequest: GET /usersResponse: 200 content-type:application/jsonRequest: POST /usersResponse: 201 content-type:application/json
    • MétodosRequest: GET /users/11Response: 200 content-type:application/jsonRequest: PUT /users/11Response: 200 content-type:application/jsonRequest: DELETE /users/11Response: 204 no content
    • HTTP: Códigos de estado
    • HTTP: Content-Type y Accept
    • Content-Type y Accept• Content-Type nos dice qué tipo de representación tiene el recurso al que estamos accediendo.• Con Accept le decimos qué tipo de representación queremos.
    • HTTP: ETag
    • HTTP: Etag y Last-Modified• Con Etag podemos controlar si el recurso se ha modificado desde la última vez que accedimos con un hash.• If-None-Match se encarga de indicar que la petición sea efectiva siempre y cuando el eTag sea distinto, If-Match hace lo inverso.• Last-Modified/If-Modified-Since permiten saber si un recurso se ha modificado en base a una fecha.
    • REST: Nivel 3Hypermedia
    • Hypermedia?
    • Hypermedia• Se basa en la idea de enlazar recursos.• Para que sea útil, el cliente debe saber que en la respuesta hay contenido hypermedia.• En content-type es clave para esto
    • <bill rel=“http://api.servicio.com/doc/order”> <id>666</id> <currency>EUR</currency> <items>..</items> <amount>67</amount> <status>UNPAID</status> <links> <link rel=“payment”> http://api.servicio.com/order/666/payment </link> <link rel=“cancel”> http://api.servicio.com/order/666/cancelation </link> </links></bill>
    • Hypermedia¿Content-Type: text/xml?
    • Hypermedia Content-Type: text/xml Content-Type:application/servicio+xml
    • RFC4627 JSON Hypertext Application Language Content-Type: application/hal+json { "_links": { "self": {"href": "/orders/523" }, "warehouse": {"href": "/warehouse/56" }, " invoice": {"href": "/invoices/873“} }, "currency": "USD", "status": "shipped", "total": 10.20 }http://tools.ietf.org/html/draft-kelly-json-hal-00
    • HerramientasCurlRestClientSwagger UI (swagger.wordnik.com)
    • Servicios3scale.comapigee.com
    • Crear un Framework REST
    • Puntos clave de un framework• Facilitarnos el trabajo• Definir una forma de trabajo común• Reducir tareas repetitivas
    • Symfony2 ComponentsHTTP FoundationRoutingClassLoaderConsole
    • HTTP Foundation• Se basa en dos objetos: Request y Response• Nos aisla de variables de entorno, servidor, headers…
    • Routing• Podemos definir URIs mediante patrones• Requisitos en las URIs de métodos HTTP y parámetros.• Varios tipos de Matcher para identificar la URI actual.
    • Console• Nos permite crear comandos para shell• Cada comando es una clase, permite definir parámetros, atributos para el comando• Los menús se generan de forma automática
    • Crear un framework REST• Crearlo sobre una aplicación real• Utilizar el componente Console para automatizar tareas repetitivas• Pensar en la organización del código
    • Crear un framework REST• Eventos• Permitir extensibilidad• Configuraciones, diferentes entornos• Logs y gestión de excepciones
    • Crear un framework REST• Sólo lo estrictamente necesario en el core• Documentación• Cobertura de tests• Aprende de otros
    • CONVENCIÓN
    • Documentación
    • Gracias :)@asiermarques