introducción a las api's rest
DESCRIPTION
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 testeoTRANSCRIPT
REST
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
REST
Representational State Transfer
● Orientado a recursos
● Uso del protocolo HTTP (cliente-servidor)
● Separation of Concerns
● Stateless
● Mecanismos de caché
● Interfaz uniforme
Rest
HTTP
TCP
REST
Nuestro ejemplo
Nuestro ejemplo
Cuenta A Cuenta B
Transferencia
Saldo Saldo
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!" }
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"}} ] }
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" }
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"}} ] }
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
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"} ] }
Recursos
SH
Bank POST /accounts/cuentaA HTTP/1.1
{ "service": "getAccount" }
HTTP/1.1 200 OK
{ "accounts": [ {"id": "cuentaA", "balance": "25M"} ] }
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" }
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"} ] }
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é." } }
Recursos
¿Y si queremos devolver una mensaje de error?
{ "error": { "name": "account.from.invalid", "message": "La cuenta de origen no es válida" } }
Verbos HTTP
Los verbos https deben ser:
● Seguros
● Idempotentes
Verbo Seguro Idempotente
GET Sí Sí
POST No No
PUT No Sí
DELETE No Sí
Verbos HTTP
SH
Bank GET /accounts HTTP/1.1
HTTP/1.1 200 OK
{ "accounts": [ {"id": "cuentaA", "balance": "25M"}, {"id": "cuentaB", "balance": "13.5K"} ] }
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" }
Verbos HTTP
SH
Bank GET /accounts HTTP/1.1
HTTP/1.1 200 OK
{ "accounts": [ {"id": "cuentaA", "balance": "25M"}, {"id": "cuentaB", "balance": "13.5K"} ] }
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
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"} ]}
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)
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.
Implementaciones de referencia
● Paypal
● Amazon S3
● Google Apis
Frameworks
● Spring MVC
● RestEasy
● Ruby On Rails
● Laravel
● Yii
● WCF .Net
Distintos niveles de caché
Caché
Escalado
Caché distribuida
API API API
Estrategias de testeo
Respuestas:
● Tipado
● Formato
● Consistencia
Funcionalidad:
● BDD (Cucumber)
● Tests de
integración
VUESTRO API ES VUESTRA TARJETA DE VISITA
Dudas
GRACIAS