Este documento describe los principios básicos de las aplicaciones RESTful con ASP.NET Core. Explica qué es REST, sus restricciones clave como interfaz uniforme y estado sin estado, y cómo implementar recursos y métodos HTTP correctamente según el modelo de madurez de Richardson. También cubre temas como el nombrado de recursos y el uso adecuado de códigos de estado HTTP.

1. Aplicaciones
RestFul con
Asp.net Core
Germán Küber
.Net Developer
http://germankuber.com.ar
@germankuber
@netbaires

2. Net-Baires
http://slack.net-baires.com
https://www.meetup.com/es-ES/Net-Baires
https://github.com/Net-Baires
@netbaires

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

22. Como interactuar con nuestros recursos

23. Nombre de recursos
Modelos externos
!=
Entity Model

24. Nombre de recursos
Modelos externos
!=
Business Model
!=
Entity Model

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
- …