3. Representational State Transfer pretende evocar una imagen de
cómo se comporta una aplicación web bien diseñada: Una red de
páginas web.
...... donde el usuario avanza a través de una aplicación
seleccionando enlaces (transiciones de estado)
...... que da como resultado la siguiente página (que representa el
siguiente estado de la aplicación) que se transfiere al usuario y se
procesa para su uso
Roy Fielding
http://bit.ly/1rbtZik
4. ¿ Que es Rest ?
• Rest es un estilo de arquitectura
• No es un estándar
• Nosotros usamos estándares para
implementarlo
• Rest es agnóstico al protocolo
5. Restricciones de Rest
• REST está definido por 6
restricciones (una opcional)
• Una restricción es una
decisión de diseño que
puede tener impactos
positivos y negativos
6. Restricciones de Rest
Client-Server
Cliente y servidor están
separados
(Cliente y servidor
pueden evolucionar por
separado)
Statelessness
Estado está contenido
dentro de la solicitud
Cacheable
Cada
respuesta/mensaje
debe indicar
explícitamente si se
puede almacenar en
caché o no
7. Restricciones de Rest
Layered System
El cliente no puede
saber a qué capa está
conectado
Code on
Demand (optional)
Servidor puede
extender la
funcionalidad del
cliente
Uniform Interface
API y los consumidores
comparten una sola
interfaz, técnica: URI,
Method, Media Type
8. Interface Uniforme
• Un recurso está conceptualmente separado de su
representación
• Tipos de medios de representación:
• application / json
• application / xml
• Custom
• ...
9. Interface Uniforme
Manipulación de recursos a través de representaciones
• Representación + metadatos deberían ser
suficientes para modificar o borrar el recurso
10. Interface Uniforme
Mensaje auto descriptivo
• Cada mensaje debe incluir información suficiente
para describir cómo procesar el mensaje
11. Interface Uniforme
Hipermedia como el motor del estado de aplicación
(HATEOAS)-
• Hypermedia es una generalización de hipertexto
(enlaces)
• Conduce cómo consumir y usar la API
• Permite una API auto-documentada
12. • La mayoría de las APIs "RESTful" no son realmente
REST
• ...... pero eso no los hace malas APIs, siempre y
cuando usted entienda los posibles trade-offs
Un sistema sólo se considera RESTful cuando se
adhiere a todas las restricciones requeridas
13. El modelo de Richardson Maturity
POST (Solicito data)
http://host/myapi
POST (Creo un recurso)
http://host/myapi
El protocolo HTTP se utiliza para la
interacción remota
El resto del protocolo no se utiliza
como debe ser
Implementación estilo RPC (SOAP, a
menudo visto cuando se utiliza
WCF)
Nivel 0 (The Swamp of POX)
14. El modelo de Richardson Maturity
POST
http://host/api/authors
POST
http://host/api/authors/{id}
Cada recurso se asigna a un URI
Los métodos HTTP no se utilizan
como deben ser
Resultados en la reducción de la
complejidad
Nivel 1 (Resources)
15. El modelo de Richardson Maturity
GET
http://host/api/authors 200
Ok (authors)
POST (author representation)
http://host/api/authors 201
Created (author)
Se utilizan los verbos HTTP
correctos
Se utilizan códigos de estado
correctos
Elimina variaciones innecesarias
Nivel 2 (Verbs)
16. El modelo de Richardson Maturity
GET
http://host/api/authors
200 Ok (authors + links that
drive application state)
La API admite Hypermedia como el
motor del estado de aplicación
(HATEOAS)
Introduce la posibilidad de
descubrir su contenido
Nivel 3 (Hypermedia)
17. Asp.net Core
• Open Source
• Multi plataforma
• Escalable
• Provee middleware
• No provee una api RestFul out of
the box
18. Nombre de recursos
Recursos no verbos
• api/getauthors
• GET api/authors
• GET api/authors/{authorId}
Sustantivos significativos
19. Nombre de recursos
Representar jerarquía al nombrar los recursos
• api/authors/{authorId}/books
• api/authors/{authorId}/books/{bookId}
20. Nombre de recursos
Filters, sorting orders, ... No son recursos
• api/authors/orderby/name
• api/authors?orderby=name
21. Nombre de recursos
Rest nos habla del contrato externo
• El resto de las capas carece de importancia
• El recurso es conceptualmente diferente al
que esta almacenado en la DB
25. Http Status Code
Level 400 – Error de cliente
400 – Bad request
401 –Unauthorized
403 – Forbidden
404 – Not found
Nivel 200 Success
200 – Ok
201 – Created
204 – No content
26. Http Status Code
Nivel 500 Error
servidor
500 – Internal server
error
Nivel 400 – Error de cliente
405 – Method not allowed
406 – Not acceptable
409 - Conflict
415 – Unsupported media type
422 – Unprocessable entity
27. Nombre de recursos
Retornar formato predeterminado
Utilizar siempre la representación
conveniente
Return 406 – Not acceptable
El formato se solicita mediante Accept
header
- application/json
- application/xml
- …
Notas del editor
Separa a las buenas aplicaciones de las excelentes aplicaciones
Errores de escalabilidad no son intuitivos
Una aplicacion escalable comienza en su diseño