Los últimos diez años han visto unos cambios drásticos en la forma de entender y diseñar las arquitecturas para las aplicaciones web. REST irrumpió a principios de la década pasada como una técnica para modelar el interfaz de estas aplicaciones ganando notoriedad sobre otros conceptos y convirtiéndose en un estándar de facto. En la charla, intentaremos aterrizar esta filosofía de desarrollo para aquellos que nunca se han enfrentado a ella, al mismo tiempo que hablaremos de algunos temas algo más avanzados. Una pequeña sinopsis de lo que trataremos: 1. Introducción 2. Modelo de madurez de Richardson • HTTP • Recursos • Verbos • HATEOAS 3. Estrategias de cacheo 4. Escalabilidad 5. Estrategias de testeo

1. REST

2. SOAP
BUSINESS
CORE
● Especificación de
protocolo
● Intercambio de
información mediante
XML
● Independiente del
protocolo de transporte
● Ampliamente usado en
la industria
● Excesivamente verboso

3. REST
Representational State Transfer
● Orientado a recursos
● Uso del protocolo HTTP (cliente-servidor)
● Separation of Concerns
● Stateless
● Mecanismos de caché
● Interfaz uniforme

4. Rest
HTTP
TCP
REST

5. Nuestro ejemplo

6. Nuestro ejemplo
Cuenta A Cuenta B
Transferencia
Saldo Saldo

7. HTTP
Petición
● Línea de petición
● Cabecera
● Cuerpo (opcional)
Respuesta
● Línea de estado
● Cabecera
● Cuerpo (opcional)
HTTP/1.1 200 OK
{ "response": “yeah!”}
POST /accountsService HTTP/1.1
{ "request": "give it to me!" }

8. HTTP
SH
Bank
POST /accountsService HTTP/1.1
{ "service": "getAccounts" }
HTTP/1.1 200 OK
{ "response": [
{"account":
{"id": "cuentaA", "balance": "25M"}},
{"account":
{"id": "cuentaB", "balance": "12K"}}
]
}

9. HTTP
SH
Bank
POST /transferService HTTP/1.1
{
"service": "doTransfer",
"fromAccount": "cuentaA",
"toAccount": "cuentaB",
"amount": 1500,
"message": "Tengo un API rara."
}
HTTP/1.1 200 OK
{ "response": "ok" }

10. HTTP
SH
Bank
POST /accountsService HTTP/1.1
{ "service": "getAccounts" }
HTTP/1.1 200 OK
{ "response": [
{"account":
{"id": "cuentaA", "balance": "25M"}},
{"account":
{"id": "cuentaB", "balance": "13.5K"}}
]
}

11. Recursos
● Uso de URI’s para identificar unívocamente un recurso
● Se usan URL’s para ello
● Podemos incluir en la cabecera negociación de
contenidos

12. Recursos
SH
Bank
POST /accounts HTTP/1.1
Content-type: application/json; charset=utf-8
{ "service": "getAccounts" }
HTTP/1.1 200 OK
{ "accounts": [
{"id": "cuentaA", "balance":
"25M"},
{"id": "cuentaB", "balance": "12K"}
]
}

13. Recursos
SH
Bank
POST /accounts/cuentaA HTTP/1.1
{ "service": "getAccount" }
HTTP/1.1 200 OK
{ "accounts": [
{"id": "cuentaA", "balance": "25M"}
]
}

14. Recursos
SH
Bank
POST /transfers HTTP/1.1
{
"service": "doTransfer",
"transfer": {
"name": 1,
"from": "cuentaA",
"to": "cuentaB",
"amount": 1500,
"message": "Tengo un API psché."
}
}
HTTP/1.1 200 OK
{ "response": "ok" }

15. Recursos
SH
Bank
POST /accounts HTTP/1.1
{ "service": "getAccounts" }
HTTP/1.1 200 OK
{ "accounts": [
{"id": "cuentaA", "balance": "25M"},
{"id": "cuentaB", "balance": "13.5K"}
]
}

16. Recursos
SH
Bank
POST /transfers/1 HTTP/1.1
{ "service": "getTransfer" }
HTTP/1.1 200 OK
{ "transfer": {
"name": 1,
"from": "cuentaA",
"to": "cuentaB",
"amount": 1500,
"message": "Tengo un API psché."
}
}

17. Recursos
¿Y si queremos devolver una mensaje de error?
{
"error": {
"name": "account.from.invalid",
"message": "La cuenta de origen no es válida"
}
}

18. Verbos HTTP
Los verbos https deben ser:
● Seguros
● Idempotentes
Verbo Seguro Idempotente
GET Sí Sí
POST No No
PUT No Sí
DELETE No Sí

19. Verbos HTTP
SH
Bank
GET /accounts HTTP/1.1
HTTP/1.1 200 OK
{ "accounts": [
{"id": "cuentaA", "balance": "25M"},
{"id": "cuentaB", "balance": "13.5K"}
]
}

20. Verbos HTTP
SH
Bank
POST /transfers HTTP/1.1
{
"transfer": {
"from": "cuentaA",
"to": "cuentaB",
"amount": 1500,
"message": "Tengo un API Restful"
}
}
HTTP/1.1 200 OK
{ "response": "ok" }

21. Verbos HTTP
SH
Bank
GET /accounts HTTP/1.1
HTTP/1.1 200 OK
{ "accounts": [
{"id": "cuentaA", "balance": "25M"},
{"id": "cuentaB", "balance": "13.5K"}
]
}

22. Verbos HTTP
Códigos de respuesta
2xx Éxito
➔ 200 Ok (puede adjuntar cuerpo)
➔ 204 No content
3xx Es necesaria una acción por parte del usuario para terminar
➔ 301 Moved permanently (adjunta cuerpo)
➔ 304 Not modified
4xx Error del cliente
➔ 404 Not found
➔ 409 Conflict (puede adjuntar cuerpo)
5xx Error en el servidor
➔ 504 Timeout

23. Hypermedia
SH
Bank
GET /accounts HTTP/1.1
HTTP/1.1 200 OK
{ "accounts": [
{"id": "cuentaA", "balance": "25M"},
{"id": "cuentaB", "balance": "13.5K"}
],
"links": [
{"href": "/transfer",
"rel": "transfer",
"method": "POST"},
{"href": "/accounts",
"rel": "create",
"method": "POST"}
]}

24. Modelo de madurez de Richardson
● Nivel 1
Usar HTTP como protocolo
● Nivel 2
Obtener recursos y no POX
● Nivel 3
Usar los verbos HTTP
● Nivel 4
HATEOAS (Hypertext as the engine of the application state)

25. Recomendaciones
● Favorecer el principio de mínima sorpresa.
● Mantener la uniformidad.
● Documentación precisa.
o Cuerpos
o Códigos de error
o Parámetros
● Si existe alguna duda, buscar
implementaciones de referencia.

26. Implementaciones de referencia
● Paypal
● Twitter
● Amazon S3
● Facebook
● Google Apis
● Instagram

27. Frameworks
● Spring MVC
● RestEasy
● Ruby On Rails
● Laravel
● Yii
● WCF .Net

29. Distintos niveles de caché
Caché

30. Escalado
Caché distribuida
APIAPI API

31. Estrategias de testeo
Respuestas:
● Tipado
● Formato
● Consistencia
Funcionalidad:
● BDD (Cucumber)
● Tests de
integración
VUESTRO API ES VUESTRA TARJETA DE VISITA

32. Dudas

33. GRACIAS