Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
INTERFACES RESTFilosofando sobre sentido de REST, eluniverso, y todo lo demás…… Y sí, esta charla durará 42 minutos Eduar...
?QUIEN SOY? Orgulloso poseedor de un Spectrum 48K Friki estándar: Amante de los videojuegos, lamúsica heavy, los juegos ...
¿CÓMO VA A SER ESA CHARLA¿Pura filosofía 
ANTES DE EMPEZAR… … unas sabias palabras¡¡¡AL LORO!!!!!¡Que no os embauquen!¡Que algunos dicen que son REST y NO lo son!
¿QUE ES REST? REST es un estilo arquitectónico que persigue la construcción desistemas altamente escalables basándose en ...
DE VERDAD… ¿QUÉ ES REST?Una forma de pensar
PIRÁMIDE DE MADUREZ DE REST
PIRÁMIDE DE MADUREZ REST – NIVEL 0 Usar HTTP como protocolo de transportePOST /appointmentService HTTP/1.1<openSlotReques...
PIRÁMIDE DE MADUREZ REST – NIVEL 1 Usar recursosPOST /doctors/mjones HTTP/1.1<openSlotRequest date = "2010-01-04"/>HTTP/1...
PIRÁMIDE DE MADUREZ REST – NIVEL 2 Usar verbos httpGET /doctors/mjones?date=20100104&status=open HTTP/1.1HTTP/1.1 200 OK<...
PIRÁMIDE DE MADUREZ REST – NIVEL 3 Usar códigos de respuesta HTTPPOST slots/1234 HTTP/1.1<appointmentRequest><patient nam...
PIRÁMIDE DE MADUREZ REST – NIVELDIOS Usar hiperenlacesGET /doctors/mjones/slots?date=20100104&status=openHTTP/1.1 200 OK<...
DISEÑANDO TU API REST
DECIDE DE QUE PARTE ESTÁSRESTafari Pragmatico
NOMBRES DE LOS RECURSOS URLs representan recursos. Recursos son cosas. Las cosas tienen nombres Usa nombres en las URL...
NOMBRES DE LOS RECURSOS ¿Nombres en plural o en singular? GET /doctors/1234 (acceso a un doctor por id) GET /doctor/123...
VERBOS HTTP Usa los verbos HTTP. GET para consultas DELETE para eliminar PUT (y POST) para editar o añadir /GET docto...
VERBOS HTTP: PUT VS POST PUT para añadir y POST para modificar. POST para añadir y PUT para modificar. PUT para añadir ...
SIMPLIFICA LAS ASOCIACIONES Limita la longitud de tu URL Intenta evitar URLs más largas que /recurso/identificador/recur...
GESTIÓN DE ERRORES Usar códigos HTTP (y opcionalmente devolver info en el payload) Usar siempre HTTP 200 y devolver info...
CÓDIGOS HTTP 3 grandes grupos de códigos 2xx: Todo ha ido bien. 4xx: Algo en la petición del cliente hace que haya habi...
CÓDIGOS HTTP 200 (OK) Úsalo como genérico de que todo ha ido bien 201 (Created) Devuélvelo para notificar que se ha cr...
CÓDIGOS HTTP 400 (Bad Request) Úsalo para indicar al cliente que debe modificar la petición. Añadeinfo en el payload. 4...
CÓDIGOS HTTP 404 (Not Found) Úsalo para informar que no se ha encontrado el recursoespecificado. Puede que la URL sea co...
CÓDIGOS HTTP 500 (Internal server Error) Úsalo para indicar que el servidor ha encontrado un error. Añadeinfo en el payl...
VERSIONAJE GET /doctors/123 Qué versión de la API usa esta URL? ¿La primera? ¿La última másactul? Si haces la versión o...
VERSIONAJE No hagas la versión opcional Especificada en URL GET /v1/doctors/1234 GET /2013-04-01/doctors/1234 GET /do...
RESPUESTAS PARCIALES GET /doctors/1234 Toda la información del doctor GET /doctors:(name, appointments)/1234 GET /doct...
MÚLTIPLES FORMATOS Hazle caso a “Accept”… … pero ofrece un mecanismo para “sobreescribir” accept GET /doctors.json/1234...
AUTORIZACIÓN Y SEGURIDAD Usa OAuth para autorizar las llamadas a tu api. No reinventes la rueda Si además de la API tie...
¿PREGUNTAS, DUDAS, CERVEZAS?Eduard Tomàs i Avellana@eiximenisetomas@pasiona.comhttp://geeks.ms/blogs/etomas
Upcoming SlideShare
Loading in …5
×

Interfaces rest

1,344 views

Published on

En esta presentación se comenta que son las interfaces REST, la pirámide de madurez de REST y algunos consejos sobre como implementar dichas interfaces

Published in: Technology, Design
  • Be the first to comment

Interfaces rest

  1. 1. INTERFACES RESTFilosofando sobre sentido de REST, eluniverso, y todo lo demás…… Y sí, esta charla durará 42 minutos Eduard Tomàs i Avellana@eiximenisetomas@pasiona.comhttp://geeks.ms/blogs/etomas
  2. 2. ?QUIEN SOY? Orgulloso poseedor de un Spectrum 48K Friki estándar: Amante de los videojuegos, lamúsica heavy, los juegos de rol de papel condados raros, la literatura fantástica y la cienciaficción Reconocido experto mundial en cervezas Trabajo en pasiona consulting Voy por ahí hablando de varias cosas gracias ala fundación Techdencias Microsoft MVP en ASP.NET/IIS
  3. 3. ¿CÓMO VA A SER ESA CHARLA¿Pura filosofía 
  4. 4. ANTES DE EMPEZAR… … unas sabias palabras¡¡¡AL LORO!!!!!¡Que no os embauquen!¡Que algunos dicen que son REST y NO lo son!
  5. 5. ¿QUE ES REST? REST es un estilo arquitectónico que persigue la construcción desistemas altamente escalables basándose en 6 premisas Cliente / Servidor Sin estado Cacheable Sistema basado en capas Interfaz unificada Code on demand
  6. 6. DE VERDAD… ¿QUÉ ES REST?Una forma de pensar
  7. 7. PIRÁMIDE DE MADUREZ DE REST
  8. 8. PIRÁMIDE DE MADUREZ REST – NIVEL 0 Usar HTTP como protocolo de transportePOST /appointmentService HTTP/1.1<openSlotRequest date = "2010-01-04" doctor ="mjones"/>HTTP/1.1 200 OK<openSlotList><slot start = "1400" end = "1450"><doctor id = "mjones"/></slot></openSlotList>
  9. 9. PIRÁMIDE DE MADUREZ REST – NIVEL 1 Usar recursosPOST /doctors/mjones HTTP/1.1<openSlotRequest date = "2010-01-04"/>HTTP/1.1 200 OK<openSlotList><slot id = "1234" doctor = "mjones" start ="1400" end = "1450"/></openSlotList>POST slots/1234 HTTP/1.1<appointmentRequest><patient name=“jsmith” /></appointmentRequest>
  10. 10. PIRÁMIDE DE MADUREZ REST – NIVEL 2 Usar verbos httpGET /doctors/mjones?date=20100104&status=open HTTP/1.1HTTP/1.1 200 OK<openSlotList><slot id = "1234" doctor = "mjones" start = "1400"end = "1450"/></openSlotList>POST slots/1234 HTTP/1.1<appointmentRequest><patient name=“jsmith” /></appointmentRequest>
  11. 11. PIRÁMIDE DE MADUREZ REST – NIVEL 3 Usar códigos de respuesta HTTPPOST slots/1234 HTTP/1.1<appointmentRequest><patient name=“jsmith” /></appointmentRequest>HTTP/1.1 201 CreatedLocation: /slots/1234/appointmentPOST slots/1234 HTTP/1.1<appointmentRequest><patient name=“jsmith” /></appointmentRequest>HTTP/1.1 409 Conflict
  12. 12. PIRÁMIDE DE MADUREZ REST – NIVELDIOS Usar hiperenlacesGET /doctors/mjones/slots?date=20100104&status=openHTTP/1.1 200 OK<openSlotList><slot id = "1234" doctor = "mjones" start = "1400"end = "1450"><link rel = "/linkrels/slot/book"uri = "/slots/1234"/></slot></openSlotList>
  13. 13. DISEÑANDO TU API REST
  14. 14. DECIDE DE QUE PARTE ESTÁSRESTafari Pragmatico
  15. 15. NOMBRES DE LOS RECURSOS URLs representan recursos. Recursos son cosas. Las cosas tienen nombres Usa nombres en las URLs, NO verbos /doctors/1234  /getDoctor/1234 
  16. 16. NOMBRES DE LOS RECURSOS ¿Nombres en plural o en singular? GET /doctors/1234 (acceso a un doctor por id) GET /doctor/1234 (acceso a un doctor por id) Suele usarse más el plural, ya que por norma generaltenemos colecciones de recursos. En todo caso evita mezclas
  17. 17. VERBOS HTTP Usa los verbos HTTP. GET para consultas DELETE para eliminar PUT (y POST) para editar o añadir /GET doctors/1234 /DELETE doctors/1234 PUT doctors/1234
  18. 18. VERBOS HTTP: PUT VS POST PUT para añadir y POST para modificar. POST para añadir y PUT para modificar. PUT para añadir y modificar POST para añadir y modificar Entonces… ¿Cuando usar PUT y POST? Respuesta: PUT debe ser idempotente. POST no tiene por qué.¡NOOOO!¡NOOOO!
  19. 19. SIMPLIFICA LAS ASOCIACIONES Limita la longitud de tu URL Intenta evitar URLs más largas que /recurso/identificador/recurso Oculta toda la complejidad en la QueryString GET /doctors/1245/appointments/20130706/refused GET /doctors/1245/appointments?date=20130706&status=refused GET /doctors/1235/patients/2341/appointments GET /patients/2341/appointments
  20. 20. GESTIÓN DE ERRORES Usar códigos HTTP (y opcionalmente devolver info en el payload) Usar siempre HTTP 200 y devolver información en el payload La primera es más REST, pero la segunda es más compatible conciertos clientes que pueden no tratar bien ciertos códigos de error(¿alguien dijo Flash?) Recomendación: Usa los códigos HTTP, pero ofrece unaalternativa para no usarlos y devolver el error en el paylaod.
  21. 21. CÓDIGOS HTTP 3 grandes grupos de códigos 2xx: Todo ha ido bien. 4xx: Algo en la petición del cliente hace que haya habido un error. Elcliente debe modificar su petición 5xx: Algo en el servidor hace que haya habido un error. El cliente NOtiene por que modificar su petición
  22. 22. CÓDIGOS HTTP 200 (OK) Úsalo como genérico de que todo ha ido bien 201 (Created) Devuélvelo para notificar que se ha creado un elemento (insert) 204 (No Content) Úsalo para indicar que todo ha ido bien y NO quieres enviarrespuesta alguna al cliente. Suele usarse en modificaciones oborrados para indicar que han ido bien.
  23. 23. CÓDIGOS HTTP 400 (Bad Request) Úsalo para indicar al cliente que debe modificar la petición. Añadeinfo en el payload. 401 (Unauthorized) Úsalo para indicar que el cliente NO está autenticado y que elrecurso requiere de clientes autenticados. Que se autentique y lopruebe de nuevo. 403 (Forbidden) Úsalo para indicar que aunque el cliente está autenticado, nopuede acceder al recurso. ¡Que no lo intente de nuevo!
  24. 24. CÓDIGOS HTTP 404 (Not Found) Úsalo para informar que no se ha encontrado el recursoespecificado. Puede que la URL sea correcta y el recurso no seencuentre. 409 (Conflict) Úsalo para indicar casos de concurrencia en modificaciones oborrados. 410 (Gone) Úsalo para informar al cliente que aunque antes había un recursoen esta URL ya no está (ni estará).
  25. 25. CÓDIGOS HTTP 500 (Internal server Error) Úsalo para indicar que el servidor ha encontrado un error. Añadeinfo en el payload.
  26. 26. VERSIONAJE GET /doctors/123 Qué versión de la API usa esta URL? ¿La primera? ¿La última másactul? Si haces la versión opcional Y es la primera, los clientes antiguos no se benefician decorrecciones o mejoras de las nuevas versiones Y es la última, los clientes antiguos pueden dejar de funcionar Y alguna vez decides que deje de ser opcional, los clientes antiguosdejarán de funcionar
  27. 27. VERSIONAJE No hagas la versión opcional Especificada en URL GET /v1/doctors/1234 GET /2013-04-01/doctors/1234 GET /doctors/1234?v=1 … Especificada en header HTTP Evita demasiadas versiones GET /v1.2.1/doctors/1234
  28. 28. RESPUESTAS PARCIALES GET /doctors/1234 Toda la información del doctor GET /doctors:(name, appointments)/1234 GET /doctors/1234&fields=name,appointments Solo nombre, citas del doctor Ofrece un mecanismo para devolver parte de la respuesta y/oañadir campos adicionales opcionales
  29. 29. MÚLTIPLES FORMATOS Hazle caso a “Accept”… … pero ofrece un mecanismo para “sobreescribir” accept GET /doctors.json/12345 GET /doctors/12345?type=json GET /doctors/12345.json
  30. 30. AUTORIZACIÓN Y SEGURIDAD Usa OAuth para autorizar las llamadas a tu api. No reinventes la rueda Si además de la API tienes una aplicación web que la consumeconsidera: Poner ambas en el mismo origen web Usar JSONP Usar CORS
  31. 31. ¿PREGUNTAS, DUDAS, CERVEZAS?Eduard Tomàs i Avellana@eiximenisetomas@pasiona.comhttp://geeks.ms/blogs/etomas

×